Skip to content
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 Linux/Arm64 runners #2536

Closed
rickardp opened this issue Jan 25, 2021 · 11 comments
Closed

Add Linux/Arm64 runners #2536

rickardp opened this issue Jan 25, 2021 · 11 comments

Comments

@rickardp
Copy link

rickardp commented Jan 25, 2021

When building Docker multiarch images, my jobs are timing out due to compilation over qemu takes too long. I know it is probably possible to set up cross compilation on x64 and move the output to some temporary storage etc, but it is a lot of work and the buildx/multiarch case is becoming very common with the Raspberry Pi and now the Apple Silicon. Any chance of setting up Arm64 runners and integrate with buildx so that the arm64 targets are built on these?

(And yes, I know you're probably building in Azure and Azure doesn't have Arm64 IIRC, but now that you're Microsoft maybe you can put the pressure on :) Arm64 in Azure would not be bad either).

Edit: Sorry about the labels, I was trying to add the "feature request" label and now I can't revert it.

@AlenaSviridenko
Copy link
Contributor

AlenaSviridenko commented Jan 25, 2021

Hi @rickardp,
unfortunately, we don't have plans to add more images now due to maintenance and possible segmentation concerns. Our current focus is on stabilizing and improving existing images. Please, consider using self-hosted runners for configurations that are not supported in GitHub-hosted runners.

Anyway, thank you for your suggestion and explained use case, it will help us to understand image popularity if we will revisit this decision in the future.

I am closing this issue. Please, feel free to create a new one in case of any other questions.

@rickardp
Copy link
Author

It's unfortunate but I can see your reasoning (also I would argue your problem is not creating the image, but fixing the infra). Self-hosted runners sort of defeats the purpose of a cloud-based build system (at least in lack of a fully managed way to provision VMs and build their images), so I hope you will revisit this decision soon as Arm64 gain popularity.

@AlenaSviridenko
Copy link
Contributor

By "maintenance" I mean a combination of things that we'll have to consider if we decide to add Arm64 runners:

  • image generation (reviewing all the software we have on current Linux images to check if it works for Arm64)
  • image deployment (which means updating infra as you mentioned)
  • team resources for supporting this image

So, yeah, you are partially right about infra, but that is not the whole picture.
Anyway, I'll escalate the request, so we will put it at our horizon.

@dennisameling
Copy link

dennisameling commented Jan 28, 2021

Just wanted to chime in here regarding hosted Linux arm64 runners. I created an example build script for lovell/sharp and ran it on both a x64 host (Windows WSL2 Ubuntu 20.04, i7-9700) and on an arm64 host (Windows WSL2 Ubuntu 20.04, Microsoft SQ1 in Surface Pro X).

The results:

x64 host (leverages Docker's arm64 emulation using QEMU)

$ time ./arm64-build-and-test.sh
....
prebuild info build Packing build/Release/sharp.node into prebuilds/sharp-v0.27.1-napi-v3-linux-arm64.tar.gz
prebuild info build Prebuild written to prebuilds/sharp-v0.27.1-napi-v3-linux-arm64.tar.gz

real    18m8.544s
user    0m0.810s
sys     0m1.052s

arm64 host

$ time ./arm64-build-and-test.sh
....
prebuild info build Packing build/Release/sharp.node into prebuilds/sharp-v0.27.1-napi-v3-linux-arm64.tar.gz
prebuild info build Prebuild written to prebuilds/sharp-v0.27.1-napi-v3-linux-arm64.tar.gz

real    4m1.470s
user    0m0.435s
sys     0m0.829s

So the difference really is night and day (~5x slower on QEMU)! Would be fantastic if the GH Actions team could consider offering native arm64 Linux runners 🤞🏼

@shaneutt
Copy link

shaneutt commented Jan 28, 2021

ARM has a lot of growing momentum. I see my customers asking for ARM builds more and more. Please consider adding support for this sooner rather than later.

@codefromthecrypt
Copy link

I know the relationship is loose, but last year Azure Pipelines added support for arm64.

Having this issue closed seems more about timing vs a won't fix, right? Other platforms such as Travis added arm64 and it would be unlikely GitHub Actions never has a free runner (I hope!)

Is there a way we can get a product manager of GitHub Actions to comment or re-open this, or in worst case point people to the correct forum for the product gap?

@rickardp
Copy link
Author

rickardp commented Sep 24, 2021

@codefromthecrypt the problem is, as far as I understand it that Azure does not expose general purpose compute nodes (VM scale sets) with arm64 CPU types. GitHub can either wait for Azure or use AWS (unlikely I suppose given ownership). I hope Azure publishes Arm64 VM sizes soon, not only because of this issue.

Azure pipelines do not have support for hosted Arm64 agents, they just have the agent software running on Arm64 (since it is .net core 3.1-based that was kind of always possible, just not always officially supported).

With this issue I was hoping for two things:

  • GitHub, being owned by MS, getting private access to the Arm64 nodes before available to the public. Based on the response, looks like this is not happening
  • the actions having native builds support for building Arm64 archs on Arm64 nodes and x64 arch's on x64 nodes, the publishing a multi arch image. Buildx has support for it but GH has to support the infra to pull it off. I guess they won't do this until the first bullet is solved based on the response here

@exchgr
Copy link

exchgr commented Mar 16, 2023

in the meantime, i've found that an efficient way to handle this gap is to cross-compile. here's an example using yarn berry (and aws ecr)

@otterley
Copy link

otterley commented Nov 1, 2023

GitHub announced the future availability (Q1 2024) of Arm64-based runners today:

https://github.blog/changelog/2023-10-30-accelerate-your-ci-cd-with-arm-based-hosted-runners-in-github-actions/

@AlexBaranowski
Copy link

Is this still actively developed? The private beta started about a half-year ago, and there is still no GA for Arm64 builders.

I understand that custom runners, cross-compilation, or even creating qemu-performance-abomination are possible solutions. However, these feel more like temporary fixes on what should be readily available, especially if GitHub aims to lead, not just follow.

Also, if you compile/build something, the ability to test it in tolerable time is quite important, so after cross-compilation (which in most cases is slower), the dynamic QA should have tolerable execution time. Without it, the whole GitHub action CI/CD solution is meaningless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants