CI is slow for macOS intel

[almet]

We've been able to run conversion tests for macOS in our CI, which increases a lot the coverage, but... takes a lot of time to run (2h30, where the rest of the CI takes 30mn).

This issue has been reported to GitHub, and we recently received a message asking us to upgrade to other runners.

For users that require the x86_64 (Intel) architecture, jobs can be migrated to one of the following labels:

macos-15-intel (new)
macos-14-large
macos-latest-large or macos-15-large

Also, it's worth noting that the intel macOS architecture will be deprecated in Fall 2027.

[almet]

I was curious about the "large-runners" and if that could help us solve the slugginess we currently see. Unfortunately, they don't seem to support nested virtalisation, making them unpractical for our use case.

Nested-virtualization and Metal Performance Shaders (MPS) are not supported due to the limitation of Apple's Virtualization Framework.

We'll have to migrate to macos-15-intel. Let's see if it fixes the speed issues.

[almet]

We'll have to migrate to macos-15-intel. Let's see if it fixes the speed issues.

Oh, we actually are already using this ru(i)nner.

Here are the options I can think about:

1. Run this nightly, or even weekly instead of in each CI run, and avoid running the full integration tests for this platform the rest of the time. We could run just one conversion in this scenario, but don't need to test all the different files as we currently do.
2. Spend more time investigating why this is slow, in the hopes to find a solution.

I'd go for 1, as I believe having a fast CI really helps keep the momentum, and we don't need to test for all the files conversion for each PR.

WDYT @apyrgio?

[apyrgio]

Thanks for opening this issue Alexis. Yeah, the time it takes for tests to run is depressingly long. Still, I propose we keep the macOS Intel test as is, right until we release 0.10.0. It's the only canonical test we have for macOS, since the one for macOS Apple Silicon uses the dummy test provider.

Now, what can we do after that? Well, the short answer is that we should go with option (1) you proposed. The longer answer though, is testing out macOS 26 runners (https://github.com/actions/runner-images/blob/main/images/macos/macos-26-arm64-Readme.md), which are currently in beta, and (I think) are M2-powered. They may be able to replace our macOS 15 Apple Silicon runners and, since they are M2-powered, may provide nested virtualization, hopefully more decent that the macOS 15 Intel runners.

[apyrgio]

Sigh, I tested against the macos-26 runner, and vfkit failed when starting the VM. I assume this means that nested virtualization is still not working on Apple Silicon runners.

[almet]

Yeah, nested virtualisation on Silicon requires m3 or higher unfortunately :(