Repository navigation
fix(ci): remove the duplicate 'with:' block from six workflows (#822) - #824
Conversation
Dependabot's #810 bump rewrote the dtolnay/rust-toolchain ref and ADDED a second `with:` block rather than editing the existing one, leaving uses: dtolnay/rust-toolchain@v1 with: toolchain: master <- orphaned, left behind with: toolchain: stable ... in place. Each affected step is fixed by deleting the orphaned first block. 12 deletions, 0 insertions, 2 lines per file. MEASURED, NOT ASSUMED --------------------- #822's body reports the symptom at ONE site (build-gossamer-gui.yml line 143). The gate reports SIX. An issue body is a dated record; the linter's own run log on 033193c lists: build-gossamer-gui.yml:143 ci.yml:43 quality.yml:118 release.yml:129 security-policy.yml:41 tests.yml:81 and prints its denominator: "6 of 32 workflow file(s) contain duplicate keys." All six are the same mechanical shape, so #822's acceptance criterion 5 (sweep the other #810 workflows) is discharged by fixing all six here rather than one. THE MUTANT IS ALREADY DEAD -------------------------- Ran the gate's own script, scripts/check-workflow-duplicate-keys.sh from hyperpolymath/standards, against both trees locally: origin/main 7e1f9fd -> rc=1, "6 of 32 workflow file(s) contain duplicate keys." this branch -> rc=0, "duplicate-key check: 32 workflow file(s) clean" Same script, same invocation, red and green, denominator printed in both directions. Reverting this commit reproduces the red, which is what criterion 4 asks for. Note why no ordinary linter caught this: the script's own header states that conventional YAML parsers silently keep the LAST duplicate and report success. Confirmed here -- yq accepted all 32 files including the six defective ones, so a yq-based check would have been vacuous. CRITERION 2 DELIBERATELY NOT IMPLEMENTED ---------------------------------------- #822 also asks that dtolnay/rust-toolchain be pinned to a commit SHA. Not done, deliberately: - dtolnay/rust-toolchain@v1 appears at 22 sites across 8 workflows. Converting the 1 site in build-gossamer-gui.yml would leave it inconsistent with 21 identical siblings and create the appearance of compliance without it. - hypatia's convention is symbolic refs, measured 40 tag/ref to 8 SHA. - .github/workflows/actions.lock ALREADY records the resolved commit for 'dtolnay/rust-toolchain@v1' (sha1-02cb101ec7c40f2c49e1d9714d64511d8e1b74de), and that lockfile gate is green as of #823. The tag is pinned by the lock; a literal SHA at one call site would desynchronise it from the lock's key. Raised as its own issue covering all 22 sites instead. NO uses: LINE IS CHANGED ------------------------ Verified: 0 'uses:' lines appear in the diff and actions.lock is not modified. This is deliberate -- it makes this PR the clean control for #818's remaining acceptance criterion, that the lockfile verify is still green on a SUBSEQUENT UNRELATED PR and not an artefact of #823's own merge commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV
|
Warning Review limit reachedNext included review available in 53 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
⚠ Read the new reds before judging this PR: they are a resurrection, not a regressionThe duplicate key was not merely reddening a linter. GitHub rejected all six workflows outright. Measured on
So these five workflows have executed nothing since #810 landed earlier today. This PR is the first time their jobs have run. What that does to the check list
The 11: None of these is caused by this change — the diff is 12 deleted lines, all of them ⚠ One thing I am not claiming: the #818's final criterion is discharged by this PR
Criterion 4 (the mutant) — already dead, locallyRan the gate's own script from Same script, both directions, denominator printed each time. Reverting reproduces the red. 🤖 Generated with Claude Code |
1 participant
Closes #822.
Deletes the orphaned first
with:block from six workflow steps. 12 deletions, 0 insertions, two lines per file.Measured, not assumed — it is six files, not one
#822's body reports the symptom at one site (
build-gossamer-gui.ymlline 143). The gate reports six, and prints its own denominator:build-gossamer-gui.ymlci.ymlquality.ymlrelease.ymlsecurity-policy.ymltests.ymlAll six are the identical mechanical shape Dependabot's #810 produced — the ref rewritten, a second
with:added rather than the existing one edited, leavingtoolchain: masterorphaned abovetoolchain: stable. So #822's acceptance criterion 5 ("sweep the other six workflows Dependabot touched, since the cause is mechanical and would repeat") is discharged by fixing all six here, not by a separate sweep.The mutant is already dead
Ran the gate's own script —
scripts/check-workflow-duplicate-keys.shfromhyperpolymath/standards— against both trees locally:origin/main@7e1f9fdrc=1— "6 of 32 workflow file(s) contain duplicate keys."rc=0— "duplicate-key check: 32 workflow file(s) clean"Same script, same invocation, red and green, denominator printed in both directions. Reverting this commit reproduces the red — which is exactly what criterion 4 asks for, so no throwaway mutant PR is needed.
⚠ Why no ordinary linter caught this. The script's own header states that conventional YAML parsers silently keep the last duplicate and report success. Confirmed directly:
yqaccepted all 32 files, including the six defective ones. A yq-based check here would have been a vacuous gate.Criterion 2 is deliberately not implemented
#822 also asks that
dtolnay/rust-toolchainbe pinned to a commit SHA. Not done, on purpose:dtolnay/rust-toolchain@v1appears at 22 sites across 8 workflows. Converting the single site inbuild-gossamer-gui.ymlwould leave it inconsistent with 21 identical siblings and create the appearance of compliance without the substance..github/workflows/actions.lockalready records the resolved commit for'dtolnay/rust-toolchain@v1'(sha1-02cb101ec7c40f2c49e1d9714d64511d8e1b74de), and that lockfile gate is green as of chore(ci): refresh actions.lock so the lockfile gate goes green (#818) #823. The tag is pinned by the lock; a literal SHA at one call site would desynchronise it from the lock's key.Raised as its own issue covering all 22 sites instead, per the standing rule that a new finding is an issue rather than a merge blocker.
This PR is also the control for #818
No
uses:line is changed andactions.lockis not modified — verified: zerouses:lines appear in the diff. That is deliberate. #818's last acceptance criterion requiresgovernance / Actions lockfile verifyto be still green on a subsequent unrelated PR, proving the fix landed onmainrather than being an artefact of #823's own merge commit. This PR is that control, and the result will be recorded on #818.🤖 Generated with Claude Code
https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV