Cirrus CI shuts down on June 1st 2026

[dnicolodi]

Acquired by OpenAI https://cirruslabs.org/...

We need to find another solution for our CI.

[rgommers]

That is a painful acquisition indeed. I've been looking at it for SciPy for a while (replacing GPU runners is hard). For meson-python, I think it's not too bad? Docker image based jobs can be moved back to GitHub Actions I'd think. Only FreeBSD I haven't found a good replacement for; https://github.com/vmactions/freebsd-vm is QEMU-based, not sure if that's worth it or we should just drop coverage.

[rgommers]

It shut down now it looks like, silently and not causing any failures or hanging jobs - probably because the Cirrus GitHub App got removed at the org level. We should fix this, because we have a coverage gap now. Marking for the next release.

[dnicolodi]

we have a coverage gap now

We should probably decide which platforms that were tested on Cirrus CI is worth testing. It has been a very long time since we found anything relevant testing on the different Linux flavors. With meson-python being used nowadays by quite a few packaged dependencies I think the distributions themselves find issues before our CI does.

[dnicolodi]

Other than the Linux flavors we lost macOS or arm64 and FreeBSD. I don't think there is an easy way to bring back FreeBSD. macOS on arm64 can be run on GitHub Actions.

[rgommers]

That all sounds right. I investigated FreeBSD options recently for NumPy, and found there were no good solutions. Spinning up a VM through some action isn't worth the effort, so dropping it sounds right.

With meson-python being used nowadays by quite a few packaged dependencies I think the distributions themselves find issues before our CI does.

They won't find anything until we release a new version, so there was some value here. Given that probably all of our users that test with meson-python's main branch will be doing that on Ubuntu, I think we may want 1-2 jobs for distros with layout differences. The current selection seems of ~10 distro flavours seems a bit excessive though.

I'll have a quick look at what we had specific problems with before.

gh-854 addressed the removal of Cirrus and adding macOS arm64 coverage.

[dnicolodi]

I think we may want 1-2 jobs for distros with layout differences

I think that testing with different installation layouts was more relevant when meson-python relied upon the exact installation path to determine where to install different components in the produced wheel. Now that it relies exclusively on abstract paths in the Meson introspection data, this is maybe less relevant. The last bugs we had to fight that depended on installation paths were not meson-python bugs but pip bugs.

On the other hands, if there is a not too complex way to test on other distributions, it definitely is not going to hurt. I am just saying that I would not spend too much effort to spin this up.

Maybe testing on a conda-forge Python would be more useful. pixi should make this straightforward, but I do not use pixi in CI anywhere yet.

[rgommers]

That's a great point, those problems indeed went away.

I'm using pixi locally for meson-python development, and in CI for SciPy, so this should be straightforward indeed. The only question is whether we want pixi.toml/pixi.lock in the root of the repo, or in .github/workflows/ so it's limited to CI only.

[dnicolodi]

The only question is whether we want pixi.toml/pixi.lock in the root of the repo, or in .github/workflows/ so it's limited to CI only.

What is the difference between these two options? To what are we committing if we add pixi.toml and pixi.lock in the root of the repo?

[rgommers]

To what are we committing if we add pixi.toml and pixi.lock in the root of the repo?

Not to anything permanent, but essentially it means that it's exposed to contributors so if they run (say) pixi run test anywhere in the repo, it'll populate the conda env if it's not already there, and then "just work". Which has some pros, like it'll become easier to contribute for those contributors (no need to figure out our dev deps). And some cons, like the trust that lock file updates are not malicious; also might lead to more churn as there will be tasks in there that aren't for CI, say pixi run build-docs.

Right now I keep my pixi.toml one directory up from the root of my clone of this repo (see here. If we add a pixi.toml in the root of the repo, it will shadow that, so basically it means that I'll need to commit all tasks I use to the repo. Maybe you can think of it similar to nox/tox, except much more powerful - but the "tasks coupled to environments are now shared" is similar.

For more complex projects like SciPy, pixi adds a ton of value. For meson-python, the dev requirements and envs are quite simple though, and we don't have many regular contributors, so maybe hiding it in .github/workflows/ may be preferred.