ci: shard PR cargo-mutants next to coverage - #679
Merged
Merged
Conversation
A ~300-mutant in-diff at -j 2 needs about 50 minutes, and the single mutants-pr job was canceled at 30. Four shards start after fmt, clippy, and test, in parallel with coverage, and stay advisory. Weekly sweep is unchanged.
This was referenced Sep 22, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hero-Gamer on #668 watched
mutants-prfind 313 mutants and get canceled at the 30-minute job cap. At-j 2that diff is about 50 minutes of work, so the advisory result was partial. reardencode's note on that thread was to free concurrent runners for more mutants jobs. #678 did the first half (short gates share one runner). This is the second half.PR mutation testing now lives in
ci.ymlas four--in-diffshards, in the same window as coverage:needs: [fmt, clippy, test], so a red fmt/clippy/test does not start the shardscargo mutants --workspace --in-diff git.diff --shard k/4 --sharding slice -j 2continue-on-error: still not a merge gate (missed mutants are expected; the Sunday 8-shard sweep stays the full-tree run)mutants.outuploaded per shardcrates/,Cargo.toml,Cargo.lock,ci.yml, ormutants.ymlWhy four shards, not two and not a count threshold: two shards of a 313-mutant diff land around 25 minutes, against the same 30-minute cap. Four lands around 12–15 minutes. Small diffs already finish in well under a minute per job, and these four start only after
test, so they do not sit in the opening burst. A dynamic "shard if count > 150" matrix is more workflow than the concurrency problem we have.Why the baseline stays, and why there is no
--timeout 240: the baseline on this tree is a few seconds and is what auto-sets the 20-second per-mutant test timeout. Skipping it (the upstream sharded example) forces a manual timeout; 240 seconds would let one hang consume the shard.-jstays 2.Weekly
mutants.ymlis unchanged apart from dropping the PR job so it is not run twice.Test plan
fmt,deny,clippy,ast-grep,test,windows,macos,coverage,nixos-module-eval)mutants-diffis success and the fourmutants (k/4)jobs start aftertest, overlapping coverage--shard k/4 --sharding slice(this diff has no Rust mutants, so they should exit after listing none)mutants.ymlno longer startsmutants-pron the pull request