Hi all! After observing that a recent regression creeped in into a stable release of wasmtime on Mac M1 (that happens in software engineering!), we at Embark Studios have decided that we needed to help with a stopgap solution to set up some CI on Mac M1, without fiddling with Github actions runner.
And here it is! Wasmtime is now being daily tested on an in-house Mac M1, as part of this public repository's CI: https://github.com/EmbarkStudios/wasmtime-aarch64-apple-darwin
While not running on every single commit, it should help us identify new test failures and notice regressions a bit quicker!
Nice! What's the trigger for that CI? Is it expected to run daily?
Finished test [unoptimized + debuginfo] target(s) in 1m 18s
also holy cow
This is great, thanks @Benjamin Bouvier and Embark!
@Alex Crichton it can be triggered manually for Embarkers, otherwise it'll run daily at 3am CET
Note the repo has been marked internal because security concerns, but the CI will still be running and reports be available at https://buildkite.com/embark-studios/wasmtime-aarch64-apple-darwin?branch=main
How to make it work?
Is there a small doc or steps to follow for this?
Would this help in running wasmtime-go in M1?
@Anirudha there's no known way to run Mac M1 CI with GitHub Actions for public repos like Wasmtime at this time. That being said being unable to actually execute the binary doesn't mean we can't do anything, we could still add a builder to simply build a release for the M1, which we don't currently do. I think, personally, that would be fine to add to our CI on the wasmtime repo
Alex Crichton said:
Anirudha there's no known way to run Mac M1 CI with GitHub Actions for public repos like Wasmtime at this time. That being said being unable to actually execute the binary doesn't mean we can't do anything, we could still add a builder to simply build a release for the M1, which we don't currently do. I think, personally, that would be fine to add to our CI on the wasmtime repo
I see. What would that look like ? If you're occupied, and can point me to what needs to be done to make it run on M1, I can help spend time on it.
I'm very new to wasmtime but it's a basic dependency for my project, and everyone else is currently on Linux machines.
@Alex Crichton Can we take this ahead on Private message if it's too noisy here?
oh either way is fine (via PM or here), but this would most likely be an edit to .github/workflows/main.yml
where other release binaries are built to add a builder for M1 macs as well (I don't know how to do this myself, I've never built for the M1)
@Alex Crichton do you mean that we should cross-compile for macOS/aarch64 from macOS/x86? That seems like definite progress if it works... but I'm curious if it does (perhaps it requires installation of a system cross-compiler at least). cc @Benjamin Bouvier for more thoughts?
@Chris Fallin AFAIK you don't need to install anything extra for cross-compilation between apple targets.
@Alex Crichton @Chris Fallin If the matter is just about building in release mode and publishing the artifacts somewhere, this is probably something we could do in automation on a daily basis too.
Could you do it once and we can test if it works?
I am unclear about what's required by publishing, and that would probably require access tokens to some package repository for wasmtime-go in particular.
I am being told that Mac M1s have arrived at MacStadium and could be used for any kind of Mac cloud stuff, if needed too!
If that hasn't been fixed more properly yet, there might be an extra step required to enable cross-compilation step for darwin/arm64: https://github.com/actions/virtual-environments/issues/2557
AFAIK rust-lang/rust figured out how to cross-compile on github actions and centralizing infrasturucture in bytecodealliance/wasmtime I think is preferable. If it's impossible to do on github actions though I think doing it on the M1 itself is reasonable
AFAIK rust runs a patched GHA runner in a VM. This patched runner disables PR builds. The VM is killed and rebuilt fresh after a certain amount of time or once the build completes to prevent any malicious code from persisting. If the queue was empty it is possible for the VM to be killed in the middle of a build as the VM has been waiting for a new job for some time.
Last updated: Dec 23 2024 at 13:07 UTC