ci: re-pin codeql-action to the true v4.38.0 commit - #97
Merged
Merged
Conversation
The pin 1c5b675653bb5c22dbe9b12b556ec555138e09fd is the commit that the annotated tag v4.38.1 dereferences to -- not v4.38.0, despite the trailing comment claiming otherwise. v4.38.1 is blocked estate-wide (nexia-list#100), so every repo carrying this pin has in fact been running the blocked version. v4.38.0 -> tag object 4bd7200e -> commit b96794f015dfd88f77b49b1c93e0fa7110f94c63 v4.38.1 -> tag object c23de5a8 -> commit 1c5b675653bb5c22dbe9b12b556ec555138e09fd Where the ref was a bare tag (@v4.38.1) it was also unpinned -- a mutable ref upstream can re-point at will -- so it is now pinned to a SHA as well as moved off the blocked version. In a number of repos the lock had already been moved to b96794f0 while the workflow was left on the blocked SHA. Those two disagree, so the workflow is currently rejected at startup and has not been running at all; this commit makes the workflow match the lock and brings it back to life. The workflow and actions.lock are changed in a single commit: GitHub compares the lock to the workflow by literal string, so a partial edit is a startup failure rather than a stale lock. Refs: hyperpolymath/standards#1005 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
|
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 ignored due to path filters (1)
📒 Files selected for processing (1)
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. (6)
|
| Layer / File(s) | Summary |
|---|---|
Update CodeQL action pins .github/workflows/codeql.yml |
The init, autobuild, and analyze steps now use commit b96794f015dfd88f77b49b1c93e0fa7110f94c63. The v4.38.0 tag and blocking metadata are unchanged. |
Priority: ➖ Normal
Estimated code review effort: 1 (Trivial) | ~5 minutes
Change: Other
Merge Risk: ⚪ Minimal · up to 78f7f
The CodeQL steps and lock metadata agree on the pinned commit, so no actionable merge risk is identified.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title clearly describes the main change: re-pinning codeql-action to the correct v4.38.0 commit. |
| Description check | ✅ Passed | The description explains the CodeQL action re-pin, the workflow and lock updates, and the intended effect. It is directly related to the changeset. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
- Commit to this branch
- Create a new PR
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
Three CodeQL steps now share the trace
The tag stays set, the block stays true
A fresh commit guides each step through
Then hops away beneath the moon
Comment @coderabbitai help to get the list of available commands.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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.
Re-pin
codeql-actionto the true v4.38.0 commitThis repo pinned
github/codeql-actionto a commit whose trailing comment said# v4.38.0.It is not v4.38.0. Dereferencing both annotated tags:
v4.38.04bd7200eb96794f015dfd88f77b49b1c93e0fa7110f94c63v4.38.1c23de5a81c5b675653bb5c22dbe9b12b556ec555138e09fdSo the pin was v4.38.1 — the version blocked estate-wide (nexia-list#100) — wearing a
v4.38.0label. The comment lied; in several repos theactions.lockrecordedref: 'v4.38.1'for the same SHA and had been telling the truth all along.Where the ref was a bare tag
@v4.38.1, it was additionally unpinned — a mutable refupstream can re-point at any time. Those are now pinned to a SHA and moved off the blocked
version.
Why one commit
GitHub compares
actions.lockto the workflow by literal string. A lock edit and a workflowedit that disagree — even for one commit — produce a
startup_failure, not a stale lock. So theworkflow
uses:, the lock'sworkflows:reference, thedependencies:record(
ref,commit, key) and any nesteduses:sub-list all move together here.Several of these workflows are dead on
mainright nowA base-state census of all 40 affected repos compared each workflow's literal
uses:ref againstits own
actions.lockentry before any change:mainactions.lockat allb96794f0…while the workflow still pins the blocked SHAstartup_failure— deadThat third row is the important one. In those repos the lock had already been moved to the
correct v4.38.0 commit and the workflow never followed, so the two disagree and GitHub rejects the
run at startup. Directly observed:
hyperpolymath/scriptsreportsCodeQL Security Analysis startup_failureon its currentmainhead.So for those repos this PR is not hygiene — it resurrects a CodeQL workflow that has not run at
all. Expect previously-absent checks to appear; a red among them is a scanner speaking for the
first time, not a regression.
The last row was measured, not assumed: a missing lock entry leaves a workflow unvalidated and it
runs normally (
metadatastician/metadatastician-governance, whose lock covers 3 of 8 workflows).Only a disagreeing entry is fatal. No lock keys are added here — adding one would newly enable
enforcement for a workflow that is currently exempt, which is a policy change, not a repair.
How this was verified before it was written
The transformer was dry-run against fetched copies of every distinct shape in the estate and the
result checked semantically at the YAML level, not by reading a diff:
codeql-actionrecord reads exactlyref: v4.38.0,commit: sha1-b96794f0…, withowner_id/repo_iduntouched;workflows:edge and every nesteduses:edge resolves to a record — the lock staystransitively closed, which is what actually keeps jobs from vanishing;
A line may only be dropped as a rename-collapse duplicate, and every drop is reported.
The dry run caught three destructive bugs before any repo was touched — an over-eager dedupe that
deleted pre-existing legitimate refs, a record-body pattern that silently dropped 12-space nested
uses:lists, and a line rebuild that ate the-of list-itemuses:.Mutation-tested, because a passing check proves nothing until it kills a mutant: blinding the
workflow rewriter and blinding the lock retarget were both caught by the cross-file lock guard;
the unmutated control reports
LOCK-OK.Expected effect
CodeQL moves from the blocked v4.38.1 to v4.38.0. Any red here that predates this commit is
pre-existing and is tracked separately under the stopping rule — a new scanner finding is an issue
with acceptance criteria, not a merge blocker.
Refs hyperpolymath/standards#1005.
🤖 Generated with Claude Code
https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm