I think that arm64 or Apple Silicon are probably better names for this these jobs. I still think it might be worth it to simply remove support for Intel Mac.

@sagudev Is there anything blocking this? Macos-13 images will be removed on december 4th, with brownouts already in november, so I think we should make sure that we run CI on arm macs before november (which is not that far off).

I still think it might be worth it to simply remove support for Intel Mac.

I would support this.

I did the rename and separated mac and arm workflows (so it will be easier to remove one). This is now possible because we do not have separate workflow for selfhosted.

Macos-13 images will be removed on december 4th, with brownouts already in november, so I think we should make sure that we run CI on arm macs before november (which is not that far off).

we can upgrade our macOS intel workflows to macOS 14 or macOS 15. i would prefer to do that and hold off on removing them entirely, since they allow us to troubleshoot macOS issues even if we don’t have access to apple hardware.

we can upgrade our macOS intel workflows to macOS 14 or macOS 15.

https://github.com/actions/runner-images

Note that the github hosted version for intel macs, are only available starting with the large tier (i.e paid), so this would only work for self-hosted.

we can upgrade our macOS intel workflows to macOS 14 or macOS 15.

https://github.com/actions/runner-images

Note that the github hosted version for intel macs, are only available starting with the large tier (i.e paid), so this would only work for self-hosted.

IIRC macos images have everything necessary for cross compilation, and I think they even have rosetta (for running smoke test).

IIRC macos images have everything necessary for cross compilation, and I think they even have rosetta (for running smoke test).

how do the build times on github-hosted macOS arm64 compare to github-hosted macOS intel and self-hosted macOS intel? if self-hosted macOS intel is faster, we may want to cross-compile to arm64 on self-hosted and use github-hosted arm64 for only the steps that actually run servo.

we can upgrade our macOS intel workflows to macOS 14 or macOS 15.

i’ve done that in #39455. i’m not against adding macOS arm64 builds, but i think we should reconsider removing macOS intel builds until we have self-hosted runners for arm64. it’s definitely on our roadmap (#38141), and very doable before macOS drops intel support in macOS 26+1.

how do the build times on github-hosted macOS arm64 compare to github-hosted macOS intel and self-hosted macOS intel? if self-hosted macOS intel is faster, we may want to cross-compile to arm64 on self-hosted and use github-hosted arm64 for only the steps that actually run servo.

We should also consider the option of renting Apple hardware for macOS arm64 builds (e.g from https://www.scaleway.com/en/apple-mac-mini). Virtualising macOS on macOS is supported on Apple hardware if we still want to use VMs, and the M4 processors would give us very fast builds.

This PR does not remove intel mac, it just adds support for arm64 mac builds.

Between this and #39455 can we reach a decision what we want to do? Only roughly 2 weeks left till the brownouts start.

Between this and #39455 can we reach a decision what we want to do? Only roughly 2 weeks left till the brownouts start.

These are two issues that are roughly independent. This PR deals with generating native arm64 build, while the other deals with image using new image (macos-14) to still build intel builds (cross-compiling and rosetta for testing).

The concurrency limit for github hosted mac runners is just 5.

Is this organisation-wide? We have a macOS runner setup for Stylo too, which I noticed was "waiting for a runner" for a while today.

Yes, I believe it is organization wide.

how do the build times on github-hosted macOS arm64 compare to github-hosted macOS intel and self-hosted macOS intel? if self-hosted macOS intel is faster, we may want to cross-compile to arm64 on self-hosted and use github-hosted arm64 for only the steps that actually run servo.

following up on this :)

the github-hosted build linked in the description took 60min to build servo and run unit tests, which is much longer than our current self-hosted macos13 builds, and completely wipes out the time savings of self-hosted runners in any builds that include macOS. do we have any thoughts on how we want to deal with that?

i’ve started working on a proposal for self-hosted macOS arm64 runners, but it will take a while for it to be finished, approved, and the monitor ported to macOS. maybe we should take the approach in #39455 for now?

the github-hosted build linked in the description took 60min to build servo and run unit tests,

The first iteration of the unit tests timed out, so I don't think this run is representative.

We're already falling back to github-hosted runners when the self-hosted runner is unavailable (which is often due to limited concurrency). Those builds (github-hosted macOS x86) are even slower: 45mins just to build (e.g. https://github.com/servo/servo/actions/runs/18493051500/job/52691223583).

Once we have self-hosted macOS arm ready to go I think we ought to think about differentiating between "self-hosted runner is down" vs "self-hosted runner is busy processing another job". Because waiting for an available self-hosted runner slot to be available is likely to be faster than running on a github-hosted in most cases!

the github-hosted build linked in the description took 60min to build servo and run unit tests,

The first iteration of the unit tests timed out, so I don't think this run is representative.

ohh thanks, i missed that. excluding the first attempt, the build only takes 16:14, which is pretty good. in that case, i think this patch is the better approach. #39455 would require us to complicate the macOS workflow by potentially cross-compiling servo depending on the runner.

I think the devtools test is flaky, because it works sometimes: https://github.com/servo/servo/actions/runs/18502354350/job/52731789703

can you post the failure in #39273? it would help us with root cause analysis :)