cargo binstall cargo-mutants falls back to a source build that fails against the pinned nightly toolchain
Summary
The scheduled mutation-testing run on 10 July 2026 (run 29091714881) failed during the Install cargo-mutants step of the reusable mutation-cargo.yml workflow, before any mutants ran. This is a distinct failure mode from the already-tracked doctest baseline issue (#66): it happened in the install step, not the baseline test run, and has not recurred in any of the ten-plus scheduled runs since.
What happened
cargo binstall --no-confirm "cargo-mutants@27.1.0" had no prebuilt binary available and fell back to cargo install, which then failed to compile:
error: failed to compile `cargo-mutants v27.1.0`, intermediate artifacts can be found at `/tmp/cargo-installETwhAq`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
Caused by:
rustc 1.90.0-nightly is not supported by the following package:
cargo-platform@0.3.3 requires rustc 1.91
Try re-running `cargo install` with `--locked`
The pinned nightly toolchain (nightly-2025-06-26, rustc 1.90.0-nightly) is older than the minimum supported Rust version pulled in transitively by an unpinned dependency (cargo-platform@0.3.3) of cargo-mutants@27.1.0. Because the install runs plain cargo install (no --locked), it resolves to the newest permitted cargo-platform release at run time rather than a version compatible with the pinned toolchain.
Where
leynos/shared-actions, .github/workflows/mutation-cargo.yml, the Install cargo-mutants step (around line 209), which runs:
cargo binstall --no-confirm "cargo-mutants@${CARGO_MUTANTS_VERSION}"with no --locked fallback and no pinned lockfile for the install.
Impact
- Run: 29091714881, schedule, 10 July 2026, 2.0 minutes, conclusion: failure.
- All six
mutants shard jobs and the parent run failed; zero mutants were exercised.
- Not recurred in any of the runs from 11 July through 20 July 2026 (all schedule/dispatch runs since are green or skip cleanly with no changes detected), so this looks like a one-off exposure to an MSRV bump in a transitive dependency of cargo-mutants rather than an ongoing outage. It remains a latent fragility: any future MSRV bump in cargo-mutants' dependency tree can break the install again with no advance warning, since binstall silently falls back to a source build when no prebuilt binary matches the runner platform/toolchain.
Proposed next step
Make the cargo binstall step robust against MSRV drift in cargo-mutants' dependency tree, e.g. by pinning to a release with a published prebuilt binary for the runner's platform (avoiding the source-build fallback), or by ensuring the toolchain used to build cargo-mutants when binstall does fall back meets the crate's current MSRV, or by failing fast with a clearer diagnostic when binstall falls back to a source build.
cargo binstall cargo-mutantsfalls back to a source build that fails against the pinned nightly toolchainSummary
The scheduled mutation-testing run on 10 July 2026 (run 29091714881) failed during the
Install cargo-mutantsstep of the reusablemutation-cargo.ymlworkflow, before any mutants ran. This is a distinct failure mode from the already-tracked doctest baseline issue (#66): it happened in the install step, not the baseline test run, and has not recurred in any of the ten-plus scheduled runs since.What happened
cargo binstall --no-confirm "cargo-mutants@27.1.0"had no prebuilt binary available and fell back tocargo install, which then failed to compile:The pinned nightly toolchain (
nightly-2025-06-26, rustc 1.90.0-nightly) is older than the minimum supported Rust version pulled in transitively by an unpinned dependency (cargo-platform@0.3.3) ofcargo-mutants@27.1.0. Because the install runs plaincargo install(no--locked), it resolves to the newest permittedcargo-platformrelease at run time rather than a version compatible with the pinned toolchain.Where
leynos/shared-actions,.github/workflows/mutation-cargo.yml, theInstall cargo-mutantsstep (around line 209), which runs:cargo binstall --no-confirm "cargo-mutants@${CARGO_MUTANTS_VERSION}"with no
--lockedfallback and no pinned lockfile for the install.Impact
mutantsshard jobs and the parent run failed; zero mutants were exercised.Proposed next step
Make the
cargo binstallstep robust against MSRV drift in cargo-mutants' dependency tree, e.g. by pinning to a release with a published prebuilt binary for the runner's platform (avoiding the source-build fallback), or by ensuring the toolchain used to build cargo-mutants when binstall does fall back meets the crate's current MSRV, or by failing fast with a clearer diagnostic when binstall falls back to a source build.