fix(ci): re-pin codeql-action to v4.38.0 SHA (#977 reverted the #973 incident fix) - #978
Merged
Merged
Conversation
Dependabot #977 (68acee7, merged 2026-09-22) bumped codeql-action from 4.38.0 back to 4.38.1 -- the version #973 had just escaped because it fails GitHub's workflow-startup validation estate-wide (nexia-list#100). Measured on hyperpolymath/standards within the hour: codeql.yml red from 12:09Z after four greens, scorecard.yml red from 11:51Z, and the newest run of each reports jobs=0. That is startup death, not a failing job; note GitHub surfaces it here as conclusion=failure, not startup_failure, because the death is in the called reusable. Five refs across three workflows went back to 1c5b675 (v4.38.1): codeql-reusable.yml init, analyze hypatia-scan-reusable.yml upload-sarif scorecard-reusable.yml upload-sarif x2 The first three are the more dangerous shape: #977 replaced the SHA but inherited #973's comment, so each line reads "@1c5b675... # v4.38.0 (4.38.1 blocked estate-wide)" -- an annotation asserting the exact opposite of the value it annotates. A reviewer reading the comment sees the safe version. scorecard-reusable.yml was never swept by #973 at all and kept honest "# v3" / "# v4.38.1" comments. Also widens the dependabot hold, which did not hold. The ignore entry named "github/codeql-action" while the workflows reference the subpath actions, and Dependabot treats github/codeql-action/init as its own dependency name -- #977's own body says "Updates `github/codeql-action/init` from 4.38.0 to 4.38.1". So the ignore matched nothing. The entry is now "github/codeql-action*". Without this the next scheduled run reopens the same PR and re-breaks both workflows. actions.lock is deliberately untouched: it already carried b96794f for all three workflows, so the lockfile was the correct side of the drift and the workflows were the stale side. Regenerating it instead -- the cure the gate's own error text prescribes -- would have written 1c5b675 back into the lock and re-legitimised the blocked version. Verified: zero refs to 1c5b675 remain under .github/; the actions-lock gate reports no error-severity and no stale findings (93 pre-existing sha-as-ref warnings are unchanged); git diff on actions.lock is empty. Refs: #973, #977, nexia-list#100, nexia-list#101, nexia-list#104 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (33)
🔇 Additional comments (5)
📝 SummarySummary by CodeRabbit
WalkthroughThe pull request broadens the Dependabot ignore pattern for CodeQL actions and updates CodeQL workflow pins to the v4.38.0 commit. Existing workflow inputs remain unchanged. ChangesCodeQL action control
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to CodeQL and SARIF scanning continue on the intended v4.38.0 pin, while Dependabot is prevented from reintroducing v4.38.1. No merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. A rabbit checks the pins in place Comment |
|
This was referenced Sep 22, 2026
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
hyperpolymath
added a commit
that referenced
this pull request
Sep 22, 2026
…37) (#979) > **Stacked on #978.** Base is `fix/scorecard-codeql-4380` so this PR shows **only** the docs-gate diff; it auto-retargets to `main` when #978 merges. **Merge #978 first.** ## The defect `check-docs-presence.sh` searched **only the repository root** for CONTRIBUTING, while estate repos have been deliberately relocating the file to `.github/` — the location GitHub itself auto-discovers. From `launch-scaffolder` `d426ea4d`: > the estate canonical location is `.github/CONTRIBUTING.md`, which GitHub auto-discovers So the gate asked *"is there a CONTRIBUTING at the repo root?"* while its consumers had been told to answer *"is there a CONTRIBUTING GitHub can find?"* — a guard asking a different question than its consumer, and the gate lost. ## Census — 516 local clones, 2026-09-22 | location | repos | |---|---| | root | 401 | | `.github/` | 96 | | `docs/` | 1 | | **none anywhere** | **94** | **19 unique repos** were being reported missing a document they demonstrably have, against **94 genuine misses**. For scale, the script's own header records a 2026-07-21 measurement over 412 real repo-root callers: README 0/412 missing, LICENSE 0/412, CONTRIBUTING **54/412**. This **widens WHERE the gate looks without widening WHAT it asks** — the 94 still block. ## Second defect, same file The failure message named only the root locations, so it prescribed a cure **narrower than the code accepts**. Surfaced only by reading the negative control's *output* rather than just its exit code. Same class as #930. ## Tests Four new accept cases — **one per added path**, because a single `.github/CONTRIBUTING.md` case would pass even if only that one path had been added — plus an **anti-overreach** case proving a CONTRIBUTING at an undiscoverable depth (`src/internal/`) still **BLOCKS**. That last one guards against a future "fix" by recursive `find`, which would silently pass all 94 genuinely-missing repos. Suite **29/29**. ## Mutants killed Both leave the pre-existing cases green, so detection is *attributable*: | mutant | result | |---|---| | gate fully reverted to root-only | 25 passed, **4 failed** — exactly the new accept cases | | only `.github/CONTRIBUTING.md` added | 26 passed, **3 failed** — each path individually load-bearing | ## Real-world controls | repo | rc | meaning | |---|---|---| | `launch-scaffolder` | 0 | the repo issue #37 reported missing | | `standards` itself | 0 | via `3-practice/` | | `cicd-suite` | 1 | genuine miss, message correct | ## ⚠ This does not close launch-scaffolder#37 by itself `launch-scaffolder`'s governance job runs this script from its **pinned** `standards` SHA, so it will not see the fix until that pin is bumped. Its `ec-linux-amd64` failure is a separate pre-existing cause and the job conclusion will not flip on this change alone — verify the CONTRIBUTING sub-check by name in the log. Refs hyperpolymath/launch-scaffolder#37, #930 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo --------- Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
What happened
Dependabot #977 (
68acee77, merged today) bumpedcodeql-actionfrom 4.38.0 back to 4.38.1 — the version #973 had escaped hours earlier because it fails GitHub's workflow-startup validation estate-wide (nexia-list#100).Measured on
hyperpolymath/standardswithin the hour:codeql.ymlscorecard.ymlThe newest run of each reports
jobs = 0— startup death, not a failing job. ⚠ GitHub surfaces it here asconclusion=failure, notstartup_failure, because the death is in the called reusable. Checking only forstartup_failurewould have missed this entirely.The five refs
codeql-reusable.ymlinit,analyzehypatia-scan-reusable.ymlupload-sarifscorecard-reusable.ymlupload-sarif×2⚠ The first three are the dangerous shape. #977 replaced the SHA but inherited #973's comment, so each line reads:
An annotation asserting the exact opposite of the value it annotates. A reviewer reading the comment sees the safe version and moves on.
scorecard-reusable.ymlwas never swept by #973 at all and kept honest# v3/# v4.38.1comments — so the unfixed file was the legible one.Why the hold did not hold
.github/dependabot.ymlalready carried a hold ongithub/codeql-action. It matched nothing: the workflows reference the subpath actions, and Dependabot treats each subpath as its own dependency name. #977's own body says "Updatesgithub/codeql-action/initfrom 4.38.0 to 4.38.1".The entry is now
github/codeql-action*. Without this the next scheduled run reopens the same PR and re-breaks both workflows.actions.lock is deliberately untouched
The lock already carried
b96794ffor all three workflows — the lockfile was the correct side of the drift and the workflows were the stale side. Regenerating it (the cure the gate's own error text prescribes) would have written1c5b675back into the lock and re-legitimised the blocked version. A lock/workflow drift has two possible stale sides and the message picks one blindly.Verification
1c5b675remain under.github/stalefindings (93 pre-existingsha-as-refwarnings unchanged)git diff --stat -- .github/workflows/actions.lock→ emptyb96794fconfirmed as the commit that tagv4.38.0peels tovalidate-actions-lock— which was blocking every commit carrying a workflow refRefs #973, #977, nexia-list#100, nexia-list#101, nexia-list#104
🤖 Generated with Claude Code
https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo