ci: adopt GitHub Actions workflow lockfile (unblocks estate-wide startup_failure) - #570
Merged
Merged
Conversation
GitHub's new workflow-lockfile enforcement kills every workflow run in
affected repos with a 0-second startup_failure ('Workflow must use a
lockfile'). The enforcement follows the call graph: callers of this
repo's reusable workflows (e.g. my-lang) are dying because the reusables
themselves have no lockfile.
Generated with gh actions-lock v0.1.6 (whole-repo pass, 38 workflows):
- adds .github/workflows/actions.lock pinning every direct and
transitive action dependency to an immutable commit SHA + hash
- rewrites uses: refs from inline SHA pins to the readable tags the
lockfile resolves (the SHA now lives in the lockfile, and tampering
is caught by hash verification before the action runs)
- dtolnay/rust-toolchain rewrites to @master are safe: every call site
already passes an explicit 'toolchain:' input
Note for future dependabot bumps: the lockfile must be regenerated
(gh actions-lock) whenever an action ref changes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Note Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime. Code Review ✅ ApprovedAdopts the GitHub Actions workflow lockfile across all 38 repository workflows to unblock estate-wide startup failures caused by enforcement policies. No issues found.
OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Important Your trial ends in 7 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more. Was this helpful? React with 👍 / 👎 | Gitar |
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
The signed-push composite pinned Asana/push-signed-commits@6e073ae which does not exist upstream (the estate's known phantom-SHA class). gh actions-lock v0.1.6 half-tolerates it: it keys the lockfile entry by the phantom ref but records the real v1.3 commit (d615ca8) as digest, making the lockfile fail its own validation ('pin key ref is a full SHA but commit digest does not match'). Re-pin to the real v1.3 SHA and rebuild; the lockfile now passes 'gh actions-lock --no-fix' cleanly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ift gate) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
hyperpolymath
disabled auto-merge
August 3, 2026 18:36
hyperpolymath
added a commit
that referenced
this pull request
Aug 3, 2026
Rebuilt on current main (post-#570). Restores all inline SHA pins, re-keys actions.lock to SHA form via scripts/relock-sha-keys.py (digest-matched, subpath-aware; run after every gh actions-lock regeneration), aligns two mislabeled erlef/setup-beam pins to the real v1.24.1 SHA, and keeps the $/ local-action migration and managed-by markers. gh actions-lock --no-fix: valid, zero errors. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
hyperpolymath
added a commit
that referenced
this pull request
Aug 3, 2026
…570) (#571) #570 merged the tag-form lockfile conversion, which breaks four estate gates (Mustfile `actions-sha-pinned`, governance workflow linter + allowlist preflight, hypatia rule — 112 findings) and collides with `sha_pinning_required`, which is now ON again — main's workflows are startup-rejected until this lands. This PR restores the estate doctrine while keeping the lockfile: - all inline SHA pins restored as before #570 (plus two mislabeled `erlef/setup-beam` pins aligned to the real v1.24.1 SHA) - `.github/workflows/actions.lock` re-keyed to SHA form via new `scripts/relock-sha-keys.py` (run after every `gh actions-lock` regeneration; digest-matched, subpath-aware) - step-level local action migrated to the `$/` form the lockfile requires - `gh actions-lock --no-fix`: valid, zero errors; fixer is at a fixpoint **Merge promptly** — main is startup-dead until then. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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.
GitHub's new workflow-lockfile enforcement kills every run in affected repos with a 0-second
startup_failure— "Workflow must use a lockfile. Rungh actions pin <workflow-path>to generate one." The banner is visible only on the run's HTML page.Enforcement follows the call graph: repos calling this repo's reusable workflows (confirmed on my-lang run 30828548623) die because the reusables at the pinned SHA have no lockfile. This PR is therefore the unblock for every affected caller in the estate — callers then re-pin to the post-merge SHA and add their own lockfile.
Generated with
gh actions-lockv0.1.6, whole-repo pass over all 38 workflows:.github/workflows/actions.lock— every direct and transitive action dep pinned to an immutable commit SHA + content hashuses:refs from inline SHA pins to readable tags; the SHA now lives in the lockfile and tampered/hijacked actions are caught by hash verification before runningdtolnay/rust-toolchain@<sha>→@masteris behavior-safe: every call site already passes an explicittoolchain:inputgh actions-lock, or runs will die at startup again.🤖 Generated with Claude Code