fix(lock): key denoland/setup-deno for governance-reusable.yml - #825
Conversation
scripts/lock-selfcheck.sh reports canon main POISON: governance-reusable.yml uses denoland/setup-deno@22d081f (added in cdec573, the 2.0.2 release) but the lock at that SHA does not key it. GitHub resolves a reusable's action refs against the CALLEE repo's actions.lock at the pinned SHA. A ref that is not keyed kills every caller at startup with zero jobs, conclusion failure (not startup_failure) and no reason in either REST or GraphQL — the gate reads as ABSENT rather than failing, so the branch looks clean. That is the exact hazard lock-selfcheck.sh (#821) was merged to catch, and it caught it on its own merge commit. The key is fully determined: the lockfile validator requires key-SHA == the digest written inline in the workflow, so this reproduces what gh actions-lock + relock-sha-keys.sh would key. Empty diff to the resolved set; no other entry moved.
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
1 participant
What
mainis POISON by this repo's ownscripts/lock-selfcheck.sh, added in #821. The gate went red on its own merge commit, and the cause predates it:The ref is used but not keyed. It arrived with
cdec573(#818, the 2.0.2 release) and no lock regeneration rode along.Why it matters
GitHub resolves a reusable's action refs against the callee repo's
actions.lockat the pinned SHA. An unkeyed ref kills every caller at workflow startup with zero jobs, conclusionfailure(notstartup_failure), and no reason carried in either REST or GraphQL — the run page is the only place that states one. A required context that dies this way never reports at all, so the gate reads as absent rather than failing and the branch looks clean.mainis not currently a safe thing to pin to.Why this fix is deterministic
The lockfile validator requires key-SHA == the digest written inline in the workflow, so the correct entry has exactly one possible value and needs no resolution, network, or judgement. This reproduces what
gh actions-lock+scripts/relock-sha-keys.shwould key, with no other entry moved.Verification
Diff is one added line in
.github/workflows/actions.lock— the key, inserted in the file's alphabetical convention.Not fixed here
lock-selfcheck.shalso reports 6 workflows with no lock entry at all (apply-workflow-pins.yml,pages-archive.yml,propagate-hooks.yml,security-gate-pr-target.yml,settings-drift-detect.yml,tag-ruleset-canon.yml— 18 refs). The gate states this is a separate question from the verdict and does not count it. Left alone deliberately: an empty[]entry is not obviously the intended answer for a workflow that may not be a reusable.Related
uses ⊆ actions.lockis red onmainwith the same root cause (it shells out toupdate-actions-lock.sh --verify-local). Expect it to clear with this change; if it does not, it is a second defect, not the same one.