Build Linux aarch64 packages using the new GH runner

[hexchain]

This PR tries to build one more artifact using the new GH ARM64 Linux runner (https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/).

I maintain the Insomnia flatpak on FlatHub (https://github.com/flathub/rest.insomnia.Insomnia) and building the application from source has been difficult. The environment for the compile/build phase is fully offline, which means any dependencies must be obtained beforehand, which in turn requires declaring them in the flatpak manifest. It is impossible to do this by hand for a large project like this. There is a tool to help generate this , but it doesn't support git sources, which this application depends on.

I've stumbled upon the news that GHA added ARM64 Linux runners and decided to give this a try. If it works and it's acceptable, hopefully we can rely on the official aarch64 linux binaries in the future.

[CLAassistant]

All committers have signed the CLA.

[jackkav]

Neat, looks like we need a linux arm build of node-libcurl I'll take a look.

[jackkav]

Update on this: recent changes to github runner environments across all OS appear to causing all the exception tests to fail on any changes to node-libcurl.

Going forward I can temporarily comment out these tests, just to see if this PR works, but ideally we would want to re-enable them before completing this work.

[hexchain]

Those 4 tests also fail locally for me, on both x86_64 and aarch64, regardless of whether the binary addon is prebuilt or not.

[filfreire]

@jackkav @hexchain we can retry with node-libcurl 2.33.7

[hexchain]

Will update after that version become available on NPM.

Out of interest, why is the node-libcurl dependency a fork? The original one also seems active at the moment. If there are non-upstreamable changes, is there any plan to rebase?

[filfreire]

If I'm not mistaken, these also need to be adapted to this change, at least pointing to x64 build for the time being

• https://github.com/Kong/insomnia/blob/develop/.github/workflows/release-publish.yml#L250
• https://github.com/Kong/insomnia/blob/develop/.github/workflows/release-publish.yml#L270

[jackkav]

Out of interest, why is the node-libcurl dependency a fork? The original one also seems active at the moment. If there are non-upstreamable changes, is there any plan to rebase?

JCMais/node-libcurl#411 (comment)

I don't believe there are significant non-upstreamable changes.

Our motivations have generally been keeping our electron/nodejs up to date, which releases every 3 months.

We are eagerly anticipating the N-API work in progress in the upstream to be completed, in order to upstream our changes and return to it. Then it will no longer be necessary for us to publish a new node-libcurl version for every nodejs upgrade. This will be a huge relief as it cut out several days of work every 2-3 months preparing node-libcurl releases.

[hexchain]

The CI should pass for aarch64 now. I'll look at the release-publish workflow later.

[hexchain]

I've updated the release-* workflows but cannot test if it works (and I'm not too confident about it)...

[jackkav]

Future work here is running a beta release and checking all the linux dist channels for the arm build. Snap craft and such.