Repository navigation
fix(ci): adopt Actions dependency lockfile (unblocks repo-wide startup_failure) - #46
Merged
Merged
Conversation
… startup_failure) Every workflow run since ~07-30 dies at startup_failure: GitHub's new workflow-lockfile enforcement rejects workflows with no actions.lock. This adopts the sanctioned fix via `gh actions-lock`: - new .github/workflows/actions.lock pinning every action (and the transitive upload-artifact inside upload-pages-artifact) to an exact commit, plus numeric owner/repo IDs (rename-hijack proof) - inline `uses: action@<sha> # vX` refs rewritten to `@vX.Y.Z` tags; the SHA authority now lives in the lockfile, which the runner enforces - exposes one lying pin comment: setup-beam@54075bc was labelled v1.18.2 but that SHA is v1.24.1 — same commit, corrected label - cross-repo standards reusables keep their existing SHA pins (out of lockfile scope) Pilot for the estate-wide outage (54/110 repos affected). 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 dependency lockfile to resolve repo-wide workflow startup failures caused by enforcement policy changes. 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}
mirror.yml and secret-scanner.yml set timeout-minutes on jobs that
`uses:` a reusable workflow — an illegal key that rejects the whole
file ("Invalid workflow file ... Unexpected value 'timeout-minutes'").
Both were latent parse-kills masked by the repo-wide lockfile outage;
the lockfile fix on this branch unmasked them.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gh actions-lock inserts its managed-by comment as line 1, pushing the SPDX header to line 2 — the Workflow security lint requires SPDX as the first line. Reorder in all 24 workflows; the locker's check mode accepts the marker on line 2. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
With actions.lock present, pin authority lives in the lockfile, so the inline 40-hex grep now false-fails every tag-style ref. Teach the check the lockfile model: verify action coverage via `gh actions-lock --verify-local` (offline), and keep the inline SHA requirement only for cross-repo reusable workflow calls, which the lockfile does not scope. Repos without a lockfile keep the original inline-SHA check. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
hyperpolymath
added a commit
that referenced
this pull request
Aug 3, 2026
Completes the revival begun in #46: the five standards-reusable callers (Governance, Hypatia scan, Secret scan, Mirror, Scorecard) were still `startup_failure` because enforcement requires a lockfile in the **called** repo at the pinned ref, and `d135b05` predates standards' `actions.lock` (standards#570). This re-pins all five to `5a597720` and aligns caller permission grants with the reusables' current demands (`actions: read` added; scorecard's job-level block carries the full union since job blocks replace top-level). If these five execute on this PR (or on main post-merge for the push-only ones), haec is the first estate repo fully through both lockfile stages — proving the consumer half of the template. 🤖 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
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.
Why
Every workflow run in this repo has been
startup_failuresince ~2026-07-30 — part of the estate-wide outage (54/110 active repos) root-caused on 08-03 to GitHub's new workflow-lockfile enforcement. The board was 16/16 green on 07-28; no repo content broke it.What
Ran
gh actions-lock(GitHub's sanctioned fix, Technical Preview):.github/workflows/actions.lockpinning all 14 distinct actions to exact commits, incl. the transitiveupload-artifactinsideupload-pages-artifact(unreachable by inline pinning), with numericowner_id/repo_id(immune to repo-rename hijack).uses: action@<sha> # vX→@vX.Y.Ztags: pin authority moves to the lockfile, which the runner enforces. Diffs stay readable; tampered refs are caught pre-run.setup-beam@54075bcwas labelled# v1.18.2, but that SHA is actually v1.24.1. Same commit, corrected label.hyperpolymath/standardsreusables keep their existing SHA pins (lockfile does not scope reusable workflow calls).This PR is itself the test
If checks on this PR execute (pass or fail) instead of
startup_failure, the root cause is confirmed fixed and this is the template for the other ~53 dead repos. Note: the Workflow security lint may flag the tag-style refs — if so, that's a linter-policy follow-up, not a reason to keep the outage.🤖 Generated with Claude Code