musllinux wheels only build on release, so breakage surfaces at release time #1150

Coming out of #1134, where the 0.22.0 release stopped on a wheel job. The specific breakage is fixed by #1146, but the reason nobody saw it coming is still there, so I wanted to write it down.

The gap

build-wheels.yml sets:

CIBW_SKIP: "${{ !inputs.build-all && '*-musllinux_*' || '' }}"

build-all is only true on release. So no musllinux wheel, on any architecture, is ever built outside a release. The first time a musllinux problem can appear is the run that is supposed to publish.

riscv64 has a second gate on top of that. The job is excluded on pull requests without the build-riscv64 label, so an unlabelled PR touching the wheel workflow builds no riscv64 wheels at all.

The two compose badly. #987 added riscv64 back in March, and cp310-musllinux_riscv64 first executed on the 0.22.0 release build (run 31476259980), where it failed on its first step. #1146 could not be validated by its own CI either, for the same reason, so it was merged on a reading of the logs and confirmed only by the next release run.

This is not really a riscv64 complaint. musllinux on x86_64 and aarch64 has the same exposure, it just has not broken yet.

Options

I do not have a favourite, and you know the cost tradeoffs here better than I do:

• A scheduled run of the wheel workflow with build-all: true, weekly or so. Catches image and toolchain drift between releases, at the cost of one long job on a timer.
• Build musllinux for one architecture on PRs that touch packaging files, rather than all of them all the time.
• Leave it, and treat a failed release build as an acceptable way to find out. That is a legitimate answer if the extra CI time is not worth it, given releases are infrequent.

A smaller related thing

The cibuildwheel version is an inline argument:

uvx --from cibuildwheel==4.1.0

dependabot.yml covers the github-actions and uv ecosystems, and neither sees that string, which is how it stayed on 4.1.0 for the two months after the image it pins was superseded. I have not thought of a tidy way to make it trackable, so this is a note rather than a proposal.

For context, I am the one who added the riscv64 entry, so this is me flagging the blind spot my own change has been sitting behind rather than pointing at anyone else's.