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

Setup arm64 linux/windows runners for AOT releases #2259

Closed
ntkme opened this issue Jun 7, 2024 · 5 comments · Fixed by #2262
Closed

Setup arm64 linux/windows runners for AOT releases #2259

ntkme opened this issue Jun 7, 2024 · 5 comments · Fixed by #2262

Comments

@ntkme
Copy link
Contributor

ntkme commented Jun 7, 2024

https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/

Specifically this can address the following:

# There is a bug in qemu's mremap causing pthread_getattr_np in musl to stuck in a loop on arm.
# Unless qemu fixes the bug or we get a real linux-arm runner, we cannot build aot-snapshot
# for arm on CI. So, we create a kernel snapshot for arm build in amd64 container instead.
# https://gitlab.com/qemu-project/qemu/-/issues/1729
- arch: arm
platform: linux/amd64 # linux/arm/v7

It allows us to build AOT for linux-arm-musl directly, as QEMU wasn't working. The Ampere CPU used by GitHub hosted runners is compatible with 32-bit arm. We can also build arm64 on arm64 runners instead of QEMU, which can speed up the build.

- arch: arm64
runner: windows-latest

It allows us to build aot for windows-arm64.

@nex3 These would require setting up two paid runners, one for linux and one for windows. As we did setup a paid macos runner in the past, is this something you can help look into?

@nex3
Copy link
Contributor

nex3 commented Jun 8, 2024

For windows, don't we have to build a script snapshot anyway to avoid code signing issues?

@ntkme
Copy link
Contributor Author

ntkme commented Jun 8, 2024

For windows, don't we have to build a script snapshot anyway to avoid code signing issues?

As long as we're not building self-contained exe, there is no code sign issue. The production release of dart runtime and dartaotruntime should be both be pre-signed. The code sign issue comes from appending snapshot to any kind of runtime exe to create a self-contained file, which invalidates the signature.

Our windows x64 release is currently AOT.

@nex3
Copy link
Contributor

nex3 commented Jun 11, 2024

I believe all you'd need to do to get these runners going is declare them in the actions file—they should pull from the same spending pool as the existing paid runners.

@ntkme
Copy link
Contributor Author

ntkme commented Jun 11, 2024

These arm runners are not public free tier, which need to be created first via https://github.com/organizations/sass/settings/actions/runners, and then it can be specified with the name define during creation.

@nex3
Copy link
Contributor

nex3 commented Jun 12, 2024

All right, I've created runners named linux-arm64 and windows-arm64.

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

Successfully merging a pull request may close this issue.

2 participants