Skip to content

Resync actions.lock and add a CI lock synchronization gate - #404

Merged
hyperpolymath merged 6 commits into
mainfrom
coderabbit/changes/597d4e2a
Sep 22, 2026
Merged

hyperpolymath merged 6 commits into
mainfrom
coderabbit/changes/597d4e2a

Conversation

@coderabbitai

@coderabbitai coderabbitai Bot commented Sep 22, 2026

Copy link
Copy Markdown
Contributor

Resync action references and dependency records in actions.lock, including an empty entry for the new gate workflow. Add a checker for missing step-level pins, stale entries, dangling dependencies, and workflow coverage, while treating unlocked reusable-workflow references as informational. Run it on pull requests and main pushes using direct Git checkout.

The five-commit range materially diverges from “Generate docstrings for PR #403”: it implements CI lockfile repairs and enforcement.

Validation: git diff --check passed. Commit history reports coverage mutation tests passed; runtime validation was not rerun.

View coding task

hyperpolymath and others added 5 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
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
@coderabbitai

coderabbitai Bot commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor Author

Review in Change Stack →

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

Important

Review skipped

This PR was authored by the user configured for CodeRabbit reviews. CodeRabbit does not review PRs authored by this user. It's recommended to use a dedicated user account to post CodeRabbit review feedback.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Essentials

Run ID: f367d1de-9df6-4117-832b-7b1500d6e884

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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

@hyperpolymath
hyperpolymath merged commit 0040c14 into main Sep 22, 2026
28 of 30 checks passed
@hyperpolymath
hyperpolymath deleted the coderabbit/changes/597d4e2a branch September 22, 2026 21:09
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