add armv7l support to scripts

[theofficialgman]

Assists with #251

Description

adds armv7l as necessary to buildscripts. There is more work that needs to be done to actually build locally on armv7l systems, as currently the windows electron-winstaller still installs on linux systems. this prevents building as electron-winstaller looks for a windows arm32 binary which does not exist. to test this, I had to fully remove windows building. the package.json. and script/package.ts will need to be reworked to not require these windows only dependencies when run on linux

the changes I made to the package-*.ts scripts will also need to be changed to allow for build time customization (instead of hardcoding them to the new values)

to help with the mapping:

deb requires: armhf or arm64
appimage requires: --armv7l or --arm64
rpm requires: armv7l or aarch64

app/src/lib/get-architecture.ts should also be updated but I'm not sure the correct format for that

you can find my arm64 and armhf manually created test builds here: https://github.com/theofficialgman/testing/releases/tag/github-desktop
(with builds for dugite-native as well)

[shiftkey]

🎨 As a first step for this work I'd happily take the API changes required to enable ARM support. I think the changes below this line will impact CI, but seeing this helps me think about how we could make this smoother (detect the environment and then pass this through to the packaging stages).

If you wanted to open a fresh PR with just those API changes let me know, otherwise I'll see if I can make time over the weekend to do the same...

[theofficialgman]

I force pushed removed those changes. making the other api changes isn't too urgent (since dugite-native still needs changes to its buildscripts as well). but this is a start (and means less patching when I go to build)

[shiftkey]

app/src/lib/get-architecture.ts should also be updated but I'm not sure the correct format for that

I believe this is just a helper module for inspecting process.arch and handling ARM emulation quirks on Windows. I think this could be extended to support other process.platform values, and if you have a working Electron build you could check what the actual values are for your ARM platforms using the dev tools (accessible from the View menu):

The docs for process.arch suggest arm or arm64 are what you should see:

/**
 * The operating system CPU architecture for which the Node.js binary was compiled.
 * Possible values are: `'arm'`, `'arm64'`, `'ia32'`, `'mips'`,`'mipsel'`, `'ppc'`,`'ppc64'`, `'s390'`, `'s390x'`, `'x32'`, and `'x64'`.
 *
 * ```js
 * import { arch } from 'process';
 *
 * console.log(`This processor architecture is ${arch}`);
 * ```
 * @since v0.5.0
 */
readonly arch: string;

I think adding these values to this type here would help us flush out some unknowns:

desktop/app/src/lib/get-architecture.ts

Line 3 in 68bd523

export type Architecture = 'x64' | 'arm64' | 'x64-emulated'

[theofficialgman]

yes, I see arm (and arm64 on the arm64 build). I'm surprised that the process arch was displayed correctly in the about page already (without editing this script)... now I'm not even sure what app/src/lib/get-architecture.ts is used for in github-desktop

oh I see... this function is only used for exception reporting really

[shiftkey]

oh I see... this function is only used for exception reporting really

Yep, I don't believe it's critical for our needs but it's a thing to keep in mind (particularly arm vs arm64 and being consistent there)...

[shiftkey]

I'm happy to flip this to "Ready for review" here now that CI is passing, unless you had extra you wanted to pull in at this stage @theofficialgman...

[theofficialgman]

oh I see... this function is only used for exception reporting really

Yep, I don't believe it's critical for our needs but it's a thing to keep in mind (particularly arm vs arm64 and being consistent there)...

no its consistent, arm referring to armv7l/armhf, and then arm64 referring to aarch64/arm64.
sorry if I was confusing, I get the correct output of arm on my arm32 build, and arm64 on my arm64 build in the about page

[theofficialgman]

unless you had extra you wanted to pull in at this stage

no not right now, you can merge. I'm not a professional developer so I don't really know the correct way of doing the things I mentioned in the first post #712 (comment)

ideally I'd like microsoft to host arm32 and arm64 linux github action runners... because until then its a bit harder to make anything with the CI (unless you host a local custom runner)

[shiftkey]

ideally I'd like microsoft to host arm32 and arm64 linux github action runners... because until then its a bit harder to make anything with the CI (unless you host a local custom runner)

I don't have access to anything that could serve as a local runner, but let's see if we can make it easier to test things locally in the near term...