Support Linux ARM64 build images
robd003 opened this issue · 39 comments
Tool name
ARM64 Linux
Tool license
new processor architecture
Add or update?
- Add
- Update
Desired version
arm64
Approximate size
No response
Brief description of tool
Now that Azure supports ARM64 could we please get GitHub actions to support building Linux ARM64 binaries using ARM64 machines?
Using cross-compiling on x86_64 systems is about 5x slower.
URL for tool's homepage
Provide a basic test case to validate the tool's functionality.
No response
Virtual environments affected
- Ubuntu 18.04
- Ubuntu 20.04
- Ubuntu 22.04
- macOS 10.15
- macOS 11
- macOS 12
- Windows Server 2019
- Windows Server 2022
Can this tool be installed during the build?
No response
Tool installation time in runtime
No response
Are you willing to submit a PR?
No response
@al-cheb Please do not close this as duplicate. @AlenaSviridenko closed #2552 because Azure did not support ARM at the time, asking to "create a new one [issue] in case of any other questions". Now, over an year later, Azure does support ARM64. So either this issue or #2552 should be re-opened
Please reconsider closing this.
Please reopen!
We plan to add this feature in the future but its not yet been prioritized.
Presumably the announcement of Arm64 VMs in Azure will make enabling this much easier?
@al-cheb do we have a timeline for this in the near future?
Any priority or eta on this?
Trying to add arm64 architecture and updating repositories leads to Azure repo 404 Not Found errors.
This would be great, currently there's a large influx of people using ARM64 servers due to Always-Free Oracle Cloud servers, I'd like to cross compile binaries to support said servers with action runners.
They did say it has not been prioritized, which likely means that there is no ETA. Everyone asking for an ETA doesn't help and is likely just going to get this issue locked...
Haven't tried it yet, but this allows to run on different architectures include ARM64:
Haven't tried it yet, but this allows to run on different architectures include ARM64:
Works like a charm!
But it is based on QEMU and it is much slower than native execution!
Haven't tried it yet, but this allows to run on different architectures include ARM64:
https://github.com/uraimo/run-on-arch-actionWorks like a charm! But it is based on QEMU and it is much slower than native execution!
Is this supported? I tried with:
env:
DOCKER_CLI_EXPERIMENTAL: enabled
jobs:
foobar:
runs-on: [arm64-ubuntu-latest]But the GitHub actions just hang with:
Waiting for a runner to pick up this job...
Using QEMU is very slow.
If you have access to an arm64 machine, you can set up self-hosted runners. Currently, there are no arm64 GitHub-hosted runners available, you can only self-host (blog).
The runner images are available for linux/arm64,linux/amd64, for instance ghcr.io/actions/actions-runner-controller/actions-runner-dind:ubuntu-20.04.
Hope that helps!
If it helps anyone, I've been using the ARM64 GitHub Actions runners provided via buildjet.com and they've been working well. I'm not associated with BuildJet in any way.
@richard-viney All I can say is thank you for mentioning buildjet. Seriously that was way too easy. Im not even going to follow this thread anymore, why wait for GH when they are a click of a button and cheaper.
We plan to add this feature in the future but its not yet been prioritized.
Can it be the future yet?
Good suggestion with BuildJet, thanks @richard-viney.
We need arm runners to build docker images for our ARM servers, and this like it should do the trick.
We need arm runners to build docker images for our ARM servers, and this like it should do the trick.
fwiw, you can use your arm64 cluster to build the arm64 images for the cluster:
jobs:
buildx:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: mkdir ~/.kube && printf "$KUBECONFIG" >> ~/.kube/config
env:
KUBECONFIG: ${{ secrets.KUBECONFIG }}
- uses: docker/setup-buildx-action@v2
with:
version: v0.9.1 # https://github.com/docker/buildx/issues/1536#issuecomment-1402004792
driver: kubernetes
driver-opts: |
namespace=docker-registry
replicas=1
requests.cpu=1
limits.cpu=4
limits.memory=2G
rootless=true
nodeselector=kubernetes.io/arch=arm64
"tolerations=key=arch,value=arm64,operator=Equal,effect=NoSchedule"
- ...ARM64 runners would be useful for testing code which may behave differently than on x86. This is probably rare, but not unlikely. With ARM becoming more and more popular, I think it is unreasonable to expect users to rely on emulation in CI when their code will run on ARM in production.
As far as I know, if one wants to build an Electron app for linux-arm using electron-builder, it has to be built on an ARM machine. So natively supporting ARM machines on GA would be really great.
This would be really helpful for me to keep my project runnings smoothly on modern M1/M2 apple machines.
I switched to BuildJet and never looked back: https://buildjet.com/
Is buildjet for ARM or ARM64? They are two different things. This thread talks about ARM64.
It says ARM but I've been using it for a few months now testing ARM64 specific SIMD intrinsics. Works really well.
https://buildjet.com/for-github-actions/docs/runners
I just ran into an issue where a test passed on AMD but failed on ARM. Would have been nice to catch this in our GitHub CI 😄
Has anyone tested BuildJet on linux and darwin with different architectures (amd, arm, arm64)?
Has anyone tested BuildJet on linux and darwin with different architectures (amd, arm, arm64)?
Yep! There were three major problems we had with BuildJet:
- We are a golang shop, and so it takes very little to configure
go build; settingGOOSandGOARCH. So we did that, and were seeing inexplicable indefinite hangs. Support indicated we ran out of memory. Who knows what was actually going on here, but we didn't waste any cycles investigating. - Queueing behind their concurrent runners is incredibly laggy and you'll be wanting more than 32 parallel, but you'll be asked to pay exorbitant amounts of cash monthly just to raise the limit by 100 cores. Not worth it for us, especially as their plans didn't go higher than 132 cores, even at the insane price points.
- Use caching of any kind? It will be incredibly slow, as nothing can beat the proximity of storage and runner colocation that GitHub has. In this case, the simple golang cache action became worthless as it spent more time uploading and downloading the than it took to download deps from scratch.
Our two goals were:
- Build arm64 artifacts natively
- Build them as fast or faster than x86_64
It didn't even need to be cheap, but considering all of the above, it was a hard-no.
Thanks for the thoughtful response! We are also struggling to find a solution to build golang module artifacts natively with different platforms. We have a forked a repository that contains go scripts for building the code, instead of running go build, so it's been really difficult cross-compiling the commands to build the artifacts. So our two solutions are 1) changing the source code to support cross-compiling (which seems like a bad idea since the maintainers abandoned support because it was hard to maintain) or 2) having Github Actions call AWS nodes in different architectures to build for it.
Hope Github starts supporting other platforms soon :)
please add arm64!!!
Please add arm support.
I'm using AWS and arm instances are way cheaper than amd64.
The only reason I can't use arm instances is that GitHub actions do not support arm.
It's just way more convenient to work with arm based images and not having to deal with multi arch, if you have an ARM based mac, so big +1 here, too ;) it would just be so much more sustainable to be able to work and build for a single platform (of choice) - think of the environment! All these wasted cpu cycles!
@arpanbag001 You could use an AWS Graviton instance as your own self-hosted runner for GitHub Actions, or you could use BuildJet. This has become a non-issue for me since I started using it. You only need to change one line in your action file. I've made dozens of builds and it hasn't even cost me anything yet.
Sigh
Agree. Sigh...
Thank you , Closing this issue as Linux Arm64 runners are available now.