Summary
Every scheduled "Mutation testing" workflow run that actually executes the
mutation-python / mutants job (i.e. is not skipped because change-detection
found no diff under cuprum/) has failed, 100% of the time, since at least
2026-07-14. Runs affected:
- 29324507069 (2026-07-14)
- 29407567654 (2026-07-15)
- 29490589502 (2026-07-16)
- 29572720283 (2026-07-17)
- 29682607161 (2026-07-19)
Runs on 2026-07-13, 2026-07-18 and 2026-07-20 show as green, but in each of
those the "Run mutation testing" step was skipped (no changes detected
under cuprum/), so they are not evidence the underlying failure has been
fixed — the step simply never ran.
Root cause
mutmut's baseline pytest run (which exercises the full test suite, not
just the module glob passed on the command line) fails on
cuprum/unittests/test_maturin_build.py::test_maturin_wheel_build_snapshot
before any mutants are generated:
File "/home/runner/work/cuprum/cuprum/mutants/cuprum/unittests/test_maturin_build.py", line 121/124, in test_maturin_wheel_build_snapshot
wheel_path = build_native_wheel_artifact(root, tmp_path / "wheelhouse")
File "/home/runner/work/cuprum/cuprum/mutants/tests/helpers/maturin.py", line 210, in build_native_wheel_artifact
subprocess.run(command, check=True, cwd=root)
subprocess.CalledProcessError: Command '[.../bin/python', '-m', 'maturin', 'build', '--release', '--out', ..., '--manifest-path', '.../rust/cuprum-rust/Cargo.toml']' returned non-zero exit status 1.
----------------------------- Captured stdout call -----------------------------
Unable to find `maturin` script
build_native_wheel_artifact (tests/helpers/maturin.py:186-216) invokes
sys.executable -m maturin build .... "Unable to find maturin script" is
emitted by the maturin PyPI package's Python entry point when it cannot
locate its own bundled/compiled binary next to the interpreter it is
running under. In the mutation-testing job this command runs inside the
ephemeral uv run --with mutmut==3.6.0 ... environment against the copied
./mutants/ tree, which evidently does not have a properly provisioned
maturin binary available to sys.executable, even though cargo/rustc
and the maturin module import succeed elsewhere in the same environment
(443–458 other tests pass in each of these runs). This is fully
reproducible: it has occurred in all five runs where the step actually
executed, with no exceptions, and always as the first baseline failure
(stopping after 1 failures).
Because mutmut aborts the whole run on a failing baseline
(mutmut_error=mutmut run failed with exit code 1 (failing baseline?)),
no mutation testing has actually happened on cuprum since 2026-07-13 on any
day where cuprum/ changed.
Separately, run 29490589502 (2026-07-16) took 75.9 minutes of wall-clock
time, but the job itself only ran for 42 seconds (11:37:37–11:38:19 UTC);
the workflow was created at 10:22:26 UTC, so roughly 75 minutes were spent
queued before a runner picked up the job. That delay is a GitHub Actions
runner-availability/scheduling artefact unrelated to the failure above (the
job failed with the identical maturin error once it finally ran), so it is
not tracked separately here.
Proposed next step
- Reproduce locally: run
uv run --with mutmut==3.6.0 mutmut run (or just
pytest cuprum/unittests/test_maturin_build.py) from a clean uv-managed
venv equivalent to the one the workflow provisions, and confirm whether
python -m maturin build fails the same way outside CI.
- Check whether
maturin needs an explicit uv sync/install step (rather
than relying on it being present via --with mutmut==3.6.0, which does
not pull in maturin) before test_maturin_wheel_build_snapshot runs
under the mutation-testing workflow's environment.
- Given this is a baseline-blocking failure, consider marking
test_maturin_wheel_build_snapshot to be excluded from the mutmut
baseline run (e.g. via mutmut's test selection options or a marker) if
building a native wheel is not meant to be part of the mutation-testing
baseline, or fix the environment so maturin resolves correctly.
Summary
Every scheduled "Mutation testing" workflow run that actually executes the
mutation-python / mutantsjob (i.e. is not skipped because change-detectionfound no diff under
cuprum/) has failed, 100% of the time, since at least2026-07-14. Runs affected:
Runs on 2026-07-13, 2026-07-18 and 2026-07-20 show as green, but in each of
those the "Run mutation testing" step was
skipped(no changes detectedunder
cuprum/), so they are not evidence the underlying failure has beenfixed — the step simply never ran.
Root cause
mutmut's baseline pytest run (which exercises the full test suite, notjust the module glob passed on the command line) fails on
cuprum/unittests/test_maturin_build.py::test_maturin_wheel_build_snapshotbefore any mutants are generated:
build_native_wheel_artifact(tests/helpers/maturin.py:186-216) invokessys.executable -m maturin build .... "Unable to findmaturinscript" isemitted by the
maturinPyPI package's Python entry point when it cannotlocate its own bundled/compiled binary next to the interpreter it is
running under. In the mutation-testing job this command runs inside the
ephemeral
uv run --with mutmut==3.6.0 ...environment against the copied./mutants/tree, which evidently does not have a properly provisionedmaturinbinary available tosys.executable, even thoughcargo/rustcand the
maturinmodule import succeed elsewhere in the same environment(443–458 other tests pass in each of these runs). This is fully
reproducible: it has occurred in all five runs where the step actually
executed, with no exceptions, and always as the first baseline failure
(
stopping after 1 failures).Because mutmut aborts the whole run on a failing baseline
(
mutmut_error=mutmut run failed with exit code 1 (failing baseline?)),no mutation testing has actually happened on cuprum since 2026-07-13 on any
day where
cuprum/changed.Separately, run 29490589502 (2026-07-16) took 75.9 minutes of wall-clock
time, but the job itself only ran for 42 seconds (11:37:37–11:38:19 UTC);
the workflow was created at 10:22:26 UTC, so roughly 75 minutes were spent
queued before a runner picked up the job. That delay is a GitHub Actions
runner-availability/scheduling artefact unrelated to the failure above (the
job failed with the identical maturin error once it finally ran), so it is
not tracked separately here.
Proposed next step
uv run --with mutmut==3.6.0 mutmut run(or justpytest cuprum/unittests/test_maturin_build.py) from a cleanuv-managedvenv equivalent to the one the workflow provisions, and confirm whether
python -m maturin buildfails the same way outside CI.maturinneeds an explicituv sync/install step (ratherthan relying on it being present via
--with mutmut==3.6.0, which doesnot pull in
maturin) beforetest_maturin_wheel_build_snapshotrunsunder the mutation-testing workflow's environment.
test_maturin_wheel_build_snapshotto be excluded from the mutmutbaseline run (e.g. via
mutmut's test selection options or a marker) ifbuilding a native wheel is not meant to be part of the mutation-testing
baseline, or fix the environment so
maturinresolves correctly.