Stream: wasmtime

Topic: Mac M1 CI


view this post on Zulip Benjamin Bouvier (Jun 01 2021 at 16:24):

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!

A (hopefully temporary) repo to run wasmtime's test on our internal aarch64-apple-darwin CD until github actions adds support - EmbarkStudios/wasmtime-aarch64-apple-darwin

view this post on Zulip Alex Crichton (Jun 01 2021 at 16:32):

Nice! What's the trigger for that CI? Is it expected to run daily?

view this post on Zulip Alex Crichton (Jun 01 2021 at 16:33):

Finished test [unoptimized + debuginfo] target(s) in 1m 18s

also holy cow

view this post on Zulip Chris Fallin (Jun 01 2021 at 16:36):

This is great, thanks @Benjamin Bouvier and Embark!

view this post on Zulip Benjamin Bouvier (Jun 01 2021 at 18:16):

@Alex Crichton it can be triggered manually for Embarkers, otherwise it'll run daily at 3am CET

view this post on Zulip Benjamin Bouvier (Jun 02 2021 at 10:11):

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

Branches for wasmtime-aarch64-apple-darwin: Pipeline for cloning and testing wasmtime on aarch64-apple-darwin

view this post on Zulip Anirudha (Sep 15 2021 at 08:49):

How to make it work?
Is there a small doc or steps to follow for this?

view this post on Zulip Anirudha (Sep 15 2021 at 08:53):

Would this help in running wasmtime-go in M1?

view this post on Zulip Alex Crichton (Sep 15 2021 at 17:42):

@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

view this post on Zulip Anirudha (Sep 16 2021 at 05:06):

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.

view this post on Zulip Anirudha (Sep 16 2021 at 05:08):

I'm very new to wasmtime but it's a basic dependency for my project, and everyone else is currently on Linux machines.

view this post on Zulip Anirudha (Sep 16 2021 at 05:09):

@Alex Crichton Can we take this ahead on Private message if it's too noisy here?

view this post on Zulip Alex Crichton (Sep 16 2021 at 14:03):

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)

view this post on Zulip Chris Fallin (Sep 16 2021 at 16:12):

@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?

view this post on Zulip bjorn3 (Sep 16 2021 at 17:23):

@Chris Fallin AFAIK you don't need to install anything extra for cross-compilation between apple targets.

view this post on Zulip Benjamin Bouvier (Sep 17 2021 at 06:05):

@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.

view this post on Zulip Anirudha (Sep 17 2021 at 06:45):

Could you do it once and we can test if it works?

view this post on Zulip Benjamin Bouvier (Sep 17 2021 at 07:22):

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.

view this post on Zulip Benjamin Bouvier (Sep 17 2021 at 08:05):

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!

view this post on Zulip Till Schneidereit (Sep 17 2021 at 12:21):

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

Description It turns out that the default toolchain in macOS 11.0 doesn't have architect arm64 support. Area for Triage C/C++ Question, Bug, or Feature? Question/Bug Virtual environments affect...

view this post on Zulip Alex Crichton (Sep 17 2021 at 13:52):

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

view this post on Zulip bjorn3 (Sep 17 2021 at 14:50):

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: Nov 22 2024 at 17:03 UTC