Summary
The scheduled mutation-testing workflow's baseline pytest run has failed intermittently four times (2026-07-08, 2026-07-09, 2026-07-10, 2026-07-14), always on the same test, always with the same error:
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pytest-of-runner/pytest-0/test_run_normalises_workspace_0/lading'
FAILED tests/unit/publish/test_run_workspace_config.py::test_run_normalises_workspace_root - FileNotFoundError: ...
Because mutmut treats a failing baseline as fatal (mutation_mutmut_error=mutmut run failed with exit code 1 (failing baseline?)), the whole job aborts before any mutants are generated.
Evidence
- Run 28931124931 (2026-07-08): baseline finished
1 failed, 274 passed in 66.62s, then aborted.
- Run 29010457746 (2026-07-09): same failure signature.
- Run 29085009600 (2026-07-10): same failure signature.
- Run 29318736113 (2026-07-14): baseline finished
1 failed, 281 passed in 59.44s, then aborted.
Why this looks like a race rather than a real regression
test_run_normalises_workspace_root (tests/unit/publish/test_run_workspace_config.py) has not changed since 2026-06-11 (commit 7498ac3), and neither tests/conftest.py nor the [tool.pytest.ini_options] / [tool.mutmut] sections of pyproject.toml changed in the window around these failures. The test calls monkeypatch.chdir(tmp_path) and then exercises publish.run; the traceback shows pytest's own tmp-path fixture directory (.../test_run_normalises_workspace_0/) disappearing out from under the test before an internal lading-relative lookup completes. That points to an environment/timing race around tmp_path creation or cleanup during the baseline run rather than a logic bug in the test or the code it exercises.
What's not the fix
The next scheduled run after the last failure (29485260995, 2026-07-16) reported success, but that run's "Detect changed files" step found no changes to lading/ in its 25-hour window and skipped the "Run mutation testing" step entirely (mutation_detect_has_changes=False) — the baseline never ran, so this was not a green re-run of the failing test. In fact, every scheduled run in this repository's history (the workflow was only added on 2026-07-06) has either skipped mutation testing for the same reason or hit this exact baseline failure; none has completed a full mutant sweep. Nothing in tests/, pyproject.toml, or the shared mutation-mutmut.yml caller between 2026-07-14 and 2026-07-16 touches this test, its fixtures, or tmp-path handling, so the failure should be considered unfixed and likely to recur the next time the baseline actually runs against a lading/ change.
Suggested next step
Investigate whether test_run_normalises_workspace_root (or a shared fixture/autouse hook it depends on) has a latent race with pytest's tmp-path allocation/cleanup when run as part of mutmut's baseline pass, and consider whether the test needs to avoid relying on tmp_path still existing after monkeypatch.chdir for the full test body, or whether pytest's tmp-path retention needs to be pinned per-run to avoid collisions between concurrent CI processes.
Summary
The scheduled mutation-testing workflow's baseline
pytestrun has failed intermittently four times (2026-07-08, 2026-07-09, 2026-07-10, 2026-07-14), always on the same test, always with the same error:Because
mutmuttreats a failing baseline as fatal (mutation_mutmut_error=mutmut run failed with exit code 1 (failing baseline?)), the whole job aborts before any mutants are generated.Evidence
1 failed, 274 passedin 66.62s, then aborted.1 failed, 281 passedin 59.44s, then aborted.Why this looks like a race rather than a real regression
test_run_normalises_workspace_root(tests/unit/publish/test_run_workspace_config.py) has not changed since 2026-06-11 (commit7498ac3), and neithertests/conftest.pynor the[tool.pytest.ini_options]/[tool.mutmut]sections ofpyproject.tomlchanged in the window around these failures. The test callsmonkeypatch.chdir(tmp_path)and then exercisespublish.run; the traceback shows pytest's own tmp-path fixture directory (.../test_run_normalises_workspace_0/) disappearing out from under the test before an internallading-relative lookup completes. That points to an environment/timing race aroundtmp_pathcreation or cleanup during the baseline run rather than a logic bug in the test or the code it exercises.What's not the fix
The next scheduled run after the last failure (29485260995, 2026-07-16) reported success, but that run's "Detect changed files" step found no changes to
lading/in its 25-hour window and skipped the "Run mutation testing" step entirely (mutation_detect_has_changes=False) — the baseline never ran, so this was not a green re-run of the failing test. In fact, every scheduled run in this repository's history (the workflow was only added on 2026-07-06) has either skipped mutation testing for the same reason or hit this exact baseline failure; none has completed a full mutant sweep. Nothing intests/,pyproject.toml, or the sharedmutation-mutmut.ymlcaller between 2026-07-14 and 2026-07-16 touches this test, its fixtures, or tmp-path handling, so the failure should be considered unfixed and likely to recur the next time the baseline actually runs against alading/change.Suggested next step
Investigate whether
test_run_normalises_workspace_root(or a shared fixture/autouse hook it depends on) has a latent race with pytest's tmp-path allocation/cleanup when run as part ofmutmut's baseline pass, and consider whether the test needs to avoid relying ontmp_pathstill existing aftermonkeypatch.chdirfor the full test body, or whether pytest's tmp-path retention needs to be pinned per-run to avoid collisions between concurrent CI processes.