-
Notifications
You must be signed in to change notification settings - Fork 970
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial support for Windows arm64 #785
Conversation
src/Misc/externals.sh
Outdated
@@ -3,6 +3,7 @@ PACKAGERUNTIME=$1 | |||
PRECACHE=$2 | |||
|
|||
NODE_URL=https://nodejs.org/dist | |||
NODE_UNOFFICIAL_URL=https://unofficial-builds.nodejs.org/download/release |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is unoffical-builds? is that trusted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NodeJS Build team can't currently publish official builds for Windows arm64 yet due to missing Hosted ARM64 runners (tracked in nodejs/build#2450 (comment)). Because of this, the NodeJS Build team is currently providing unofficial builds at that URL.
Compilation support for ARM64 is at Tier 2, meaning that they will only release new versions if NodeJS is guaranteed to compile on arm64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would the existing node we package work on the windows arm64 through an emulation layer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bryanmacfarlane it would indeed, however it would result in a loss of performance and process.arch
would also return x64
in that case. We should actually be very close to official arm64 builds, so may I suggest that we wait 2-3 more weeks? Otherwise I'm happy to update this PR to use x64
Node until the native version becomes available.
@chrispat @thejoebourneidentity for this. |
@@ -22,6 +22,20 @@ Add-Type -AssemblyName System.IO.Compression.FileSystem ; | |||
[System.IO.Compression.ZipFile]::ExtractToDirectory("$PWD\actions-runner-win-x64-<RUNNER_VERSION>.zip", "$PWD") | |||
``` | |||
|
|||
## Windows arm64 (Pre-release) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be upper-case ARM
, i.e. ARM64
instead of arm64
?
bc86398
to
5cb042b
Compare
47be76f
to
0033a91
Compare
0033a91
to
366d815
Compare
366d815
to
9878238
Compare
This has worked pretty well for me for making a Raspberry Pi Windows ARM64 runner. Fast it ain't, but it's better than the nothing that's available in hosted runners. I just had to rebase and rebuild (CI) because a new version was released and auto-update failure (not finding a windows-arm64 version) was apparently fatal. Upgrading from a 3B+ to a 4B 8GB model with a USB3 flash drive has really helped with speed. |
Yep, had the same issue where the auto-update process got in a loop. Just rebased and rebuilt it as well, and it's once again running really well on my Surface Pro X 🚀 |
Time for another rebase, my runner quit on me again 😖 One minor issue I see is that the CI job "Package Release" step results in "Packaging actions-runner-win-x64-2.280.2" on arm64, and the zip file inside the artifact zip says x64.
|
9878238
to
61a7ffc
Compare
@jeremyd2019 When building on an x64 host the following works for me:
It simply creates |
I see. runner/.github/workflows/build.yml Line 64 in 04679b5
Needs runner/.github/workflows/release.yml Line 99 in 04679b5
|
fd70441
to
ae1594a
Compare
ae1594a
to
714e529
Compare
714e529
to
2a685e5
Compare
2a685e5
to
a302aa0
Compare
Hello, is this scheduled for review by the actions team? |
rebasing onto v2.285.0 finally got a conflict, because they added node16 support. And it looks like the unofficial build for 12.22.7 for windows-arm64 is not there |
a302aa0
to
8988ab7
Compare
Have just rebased. The code is now ready for the situation where the NodeJS team will be publishing official ARM64 builds, which hopefully will be happening soon: nodejs/build#2540 |
As a workaround for the time being, it seems the server is not trying to force my runner to update if it is registered as ephemeral (despite #1396 not being done yet). And I've read on other issues that you can just lie in your runner's version as something greater than the released version, and that will make the auto-update STFU. But I'd much rather actually be able to keep my ARM64 runner up-to-date. |
It looks like this has finally been done in https://github.com/actions/runner/releases/tag/v2.297.0 (#2022). I had been rebasing this against new releases of the runner to keep my runner going, but now I can try out the "official" unofficial build! 🎉 |
Closing this out in favor of the official unofficial builds, but thanks for all teh work you've done here @jeremyd2019 . Let us know if you see any issues in the "official" release |
I wanted to test if it's possible to cross-compile GitHub Actions for Windows arm64, turns out it works! 🚀
Here's an example release with the arm64 binaries: https://github.com/dennisameling/runner/releases/tag/v2.273.6-win-arm64
UPDATE December 28 2020: rebased against the recent .NET 5 upgrade. New release: https://github.com/dennisameling/runner/releases/tag/v2.275.1-win-arm64 - confirmed to work on Surface Pro X including the RunnerService 👍🏼
I was even able to add a self-hosted runner on my Surface Pro X with the arm64 binaries:
Running as a Windows service also works:
I know I haven't discussed this in a Feature Request here before to ask for the feature, but would appreciate if the team wants to consider this PR. It would bring Windows arm64 to a pre-release state, just like Linux arm64 and arm.
Thanks in advance!