Skip to content

Fix/actions lock desync - #407

Merged
hyperpolymath merged 5 commits into
mainfrom
fix/actions-lock-desync
Sep 23, 2026
Merged

hyperpolymath merged 5 commits into
mainfrom
fix/actions-lock-desync

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Summary

Closes #

Type of change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (would change existing behaviour)
  • 🕳️ Soundness fix (fixes a checker/proof false-negative)
  • 📖 Documentation
  • 🧹 Refactor / tech debt (behaviour-preserving)
  • ⚡ Performance
  • 🔧 Build / CI / tooling

How has this been verified?

Checklist

  • My commits are signed (git commit -S).
  • I ran the project's own checks/tests locally and they pass.
  • New files carry the correct SPDX-License-Identifier (code/config MPL-2.0,
    prose CC-BY-SA-4.0); I did not relicense existing files.
  • Docs are updated, and no public claim now overstates what the code does.
  • I have not introduced a soundness hole (or I have flagged where I might have).

Notes for reviewers

hyperpolymath and others added 4 commits September 22, 2026 18:48
GitHub refuses a run at startup, creating zero jobs, when a workflow
carries a `uses:` ref that the lockfile does not record under that
workflow's own path. It matches by LITERAL STRING; `gh actions-lock`
matches by resolved commit, so a lock entry naming a tag that
dereferences to the pinned SHA passes the tool and still kills the run.

Regenerate the lock, make it transitively closed, and add a lock-sync
gate carrying no `uses:` of its own so it cannot be disabled by the
desync it detects. No workflow YAML is modified.

Refs: hyperpolymath/standards#968

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
A workflow absent from actions.lock can be rejected at startup (startup_failure,
jobs=0) even when it carries zero real 'uses:' refs and so has nothing to pin.
The gate is deliberately zero-'uses:', which is exactly why it had no entry.

Measured on two repos in this batch: adding this single line flipped the gate
from 7 consecutive startup_failure runs to success on hyperpolymath/verisimdb
(two successes since, nothing else changed) and from 2 of 2 startup_failure to
success on hyperpolymath/blocky-writer.

Enforcement is not uniform across repos — 13 of the 14 repos in this batch start
the byte-identical gate today with the same gap. A repo that passes now is not
evidence its lock is complete, only that the behaviour has not reached it. This
closes the gap before it bites.

Zero-'uses:' workflows take the empty list, matching the entries actions.lock
already carries for other zero-'uses:' workflows such as labels.yml.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
The gate could not defend the fix this PR ships. Clauses 1-3 ask "is every
`uses:` locked under its own workflow path?" GitHub asks a DIFFERENT question:
"is every workflow FILE represented in the lock?" A workflow with no `uses:`
satisfies clauses 1-3 vacuously and GitHub still refuses to start it - which is
exactly how lock-sync-gate.yml failed here 7 times running while the checker
reported the lock in sync. Thirteen other repositories passed the gate with the
same gap present, so a green gate was not evidence of a complete lock.

Clause 4 diffs the set of files under .github/workflows/ against the set of
lockfile keys, fails on any file with no key, names it, and quotes the
empty-list form to add. Remediation step 4 warns that re-running
`gh actions-lock` may not fix it, because omitting the file is the tool's own
defect.

Mutation-tested both ways: deleting the lock-sync-gate key fails the gate, and
deleting the unrelated labels.yml key fails it too; the unmutated tree passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
…ifier validity bit

The ref is NOT required: GitHub does not enforce job-level reusable `uses:`
at startup, and the standards verifier explicitly accepts it
(`workflow_references_reusable_dependency`). But `gh actions-lock` v0.1.6 still
reports it as `stale`, which flips the tool's `valid` bit to false. That moves
the tree off the `valid == true` early return and into the finding loop, where
the standards SHA pinned here (8f2ee508) has no advisory-category filter -- so
PRE-EXISTING `sha-as-ref` advisories are counted as blocking.

Measured on bofj-kitt: `governance / Actions lockfile verify` was success on
main and failure here, with the same two advisories present in both trees.
Removing the ref (and its now-orphaned `dependencies:` record) restores
`valid = true` and the early return.

Verified offline against the verifier fetched at the PINNED standards SHA:
exit 0, matching main. No workflow YAML is touched.

Also corrects the lock-sync checker's own documentation: clause 1 is enforced
at STEP level only, so the header and success message no longer claim job-level
reusable refs are locked (raised in review; the checker's behaviour is
unchanged and still kills a mutant).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
@coderabbitai

coderabbitai Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

✨ Finishing Touches
📝 Generate docstrings
  • 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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
@hyperpolymath
hyperpolymath merged commit 9ffb817 into main Sep 23, 2026
18 of 21 checks passed
@hyperpolymath
hyperpolymath deleted the fix/actions-lock-desync branch September 23, 2026 09:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant