lock-sync gate: list it in actions.lock (cures 7 startup failures) + clause 4 coverage check - #287
Merged
Merged
Conversation
The gate is the one workflow in this repo with no manual trigger, so when it fails at startup there is no way to re-observe it: `gh run rerun` refuses a startup_failure, and the only other triggers are `pull_request` and `push` to main. That left verisimdb with six startup_failures and no way to take a clean seventh measurement. Adding `workflow_dispatch:` costs nothing (the gate still carries zero real `uses:` refs, so it cannot desync against actions.lock) and makes the gate re-observable on demand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
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 (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. (25)
🔇 Additional comments (1)
📝 SummarySummary by CodeRabbit
WalkthroughThe lock-sync gate workflow now supports manual execution through ChangesLock-sync gate workflow
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Feature Merge Risk: ⚪ Minimal · up to The workflow is mergeable; this change enables manual gate runs without altering existing triggers or behavior. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🛠️ Fix failing CI checks
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 taps the workflow door Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
verisimdb's actions.lock lists 24 of its 25 workflow files. The single omission is lock-sync-gate.yml, and it is the single workflow that cannot start: 7 of 7 runs are startup_failure, including one 22 minutes before and one 3.5 hours after the estate-wide startup incident window, plus a minimal zzz-probe.yml that died the same way on 2026-08-03. The gate carries zero real 'uses:' refs by design, so its entry is the empty list. This tests whether GitHub requires every workflow to be represented in actions.lock once the lockfile exists, rather than only those with refs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm
The lock-entry commit flipped the gate from 7 consecutive startup_failure runs to success. That is one observation. This empty commit takes a second, with the cured actions.lock unchanged, to distinguish a cure from a coincidence. 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
hyperpolymath
changed the title
Contributor
|
✅ Coding Agent task started: View task and status The task will inspect the CI failures, validate its fix, and commit the fix to this branch automatically.
⏭️ 1 check(s) skipped — already failing on `main` (not caused by this PR)
|
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 this fixes
lock-sync-gate.ymlin this repository failed 7 consecutive times withstartup_failureandjobs=0, while every sibling workflow started normally onthe same pushes. The cause is now identified and cured.
Cause
A workflow file with no key in
.github/workflows/actions.lockis refused byGitHub at startup even when it contains zero
uses:refs and therefore hasnothing to pin. This repository's lock listed 24 of its 25 workflow files;
the one omission was the gate itself.
The fix is one line, in the spelling
gh actions-lockalready uses for otherzero-
uses:workflows in this same lockfile (labels.yml):Evidence — single-variable flip, reproduced independently
hyperpolymath/verisimdb(here)startup_failurehyperpolymath/blocky-writerstartup_failureA control commit that touched the tree but not the lock still failed, and an
empty commit after the cure passed — so this is a property of the lock's
contents, not a re-indexing side effect of any lock change.
that the cluster of failures was a platform incident inside a
13:49:37Z–14:20:14Z window, with
workflow_dispatch:added as an observabilityhandle to test that. That theory was wrong for this repo. The window does
explain the other 13 repositories — each had succeeded at least once and only
failed inside it — but this repository had never succeeded once (0/6, plus a
minimal probe workflow dying the same way seven weeks earlier). The per-repo
success/failure tally is what separated the two diseases.
The gate could not defend its own fix
uses:locked under its own workflow path?A workflow with no
uses:satisfies clauses 1–3 vacuously and is stillrefused — which is precisely how this gate died 7 times while its own 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 (COVERAGE), added here, diffs the set of files under
.github/workflows/against the set of lockfile keys and fails on any file withno key, naming it and quoting the empty-list form. Remediation step 4 warns that
re-running
gh actions-lockmay not fix it, because omitting the file is thetool's own defect.
Mutation-tested, both directions
lock-sync-gate.ymlkeylabels.ymlkeyAlso included
workflow_dispatch:on the gate. A startup-failed run cannot be re-run(
gh run rerunrefuses it), which is what made this defect expensive todiagnose; a dispatch handle makes it reproducible on demand. It is kept as a
permanent affordance, not as the fix.
Residual reds on this PR
governanceandhypatia-scanfail for an unrelated, already-filed cause —phantom blob pins of the
standardsreusable workflows(
hyperpolymath/standards#987).Security Scanandrust-ciare their ownpre-existing cases. None is a regression from this change; per the stopping rule
they are issues, not blockers.
🤖 Generated with Claude Code
https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm