fix(ci): adopt Actions workflow lockfile — cures repo-wide startup_failure - #341
Conversation
…rtup_failure Every workflow run since 2026-07-27 22:45 died as a 0-second startup_failure with zero jobs. Root cause (readable only as a banner on the run's HTML page): GitHub's new workflow-lockfile enforcement — 'Workflow must use a lockfile.' This change: - adds .github/workflows/actions.lock, generated by gh actions-lock v0.1.7-rc.1, pinning every step-level action (and transitive composite deps) to a verified commit SHA - rewrites step-level 'uses:' refs to the symbolic form the lockfile system expects (SHAs now live in the lockfile, visible in PR diffs) - replaces two phantom dtolnay/rust-toolchain SHAs (commits reachable from no tag or branch — could never resolve) with @stable, which the lockfile pins and which restores the action's ref-as-toolchain semantics - fixes three latent parse defects unmasked once runs could start: duplicate job-level timeout-minutes in codeql.yml, and illegal timeout-minutes on the reusable-caller jobs of hypatia-scan.yml and generator-generic-ossf-slsa3-publish.yml - keeps SPDX headers on line 1 (Workflow Security Linter requirement) with the actions-lock marker on line 2 Verified on probe/actions-lockfile: Lockfile Probe success (1 real job), Chapel Accelerator CI success (3 jobs) — the first successful runs in this repository since 2026-07-27. Pure reusable-caller workflows need no lockfile entry; zero-dep inline workflows need a hand-added empty entry (gh actions-lock skips them). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
|
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 new GitHub Actions workflow lockfile and pins step-level action SHAs to resolve repo-wide startup failures, while fixing latent YAML parse defects. 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 |
…eaked audit file The Governance run banner on this PR reads: 'The following workflows are missing a lockfile: .github/workflows/governance.yml' — enforcement requires EVERY workflow to appear in actions.lock, including pure reusable callers, which gh actions-lock skips. Empty entries added for the 8 callers (same cure as the zero-dep probe in #341). main-estate-audit.yml was untracked scratch swept in by 'git add' — removed from the branch; it references the nonexistent hyperpolymath/cicd-suite repo and lacks an SPDX header (it caused both the Central Estate CI/CD Audit startup_failure and the Workflow Security Linter red on this PR). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Caller-side lockfile enforcement demands `actions.lock` in the called repo **at the pinned ref**. standards shipped its lockfile (#570/#571/#572); these 7 callers still pinned pre-lockfile SHAs, so they remained `startup_failure` after #341 unbricked the inline workflows. Re-pins governance, hypatia-scan, mirror, rust-ci, scorecard, secret-scanner, spark-theatre-gate to `fcb8669169b4` (standards main, 2026-08-04). Every pin verified resolvable via the commits API. **Expected on this PR**: the callers *start* (real jobs/conclusions). Honest reds are possible — the governance/hypatia reusables float ahead of echidna's 07-28 baseline — and are follow-up content work, strictly better than a gate that never runs. **Not fixed here**: `security-scan.yml` calls `hyperpolymath/panic-attack`, which needs its own lockfile first. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
What
Every workflow run in this repository has died as a 0-second
startup_failurewith zero jobs since 2026-07-27 22:45 — 100% of runs, on main and every branch. The root cause is GitHub's new workflow-lockfile enforcement; the reason is readable only as a banner on the run's HTML page (invisible to REST/GraphQL/logs):This PR:
.github/workflows/actions.lock(generated bygh actions-lockv0.1.7-rc.1), pinning every step-level action and transitive composite dependency to a verified commit SHAuses:refs to the symbolic form the lockfile system expects — the SHAs now live in the lockfile, where bumps show up in PR diffsdtolnay/rust-toolchainSHAs (commits reachable from no tag or branch — they could never have resolved) with@stable, which the lockfile pins and which restores the action's ref-as-toolchain semanticscodeql.yml: duplicate job-leveltimeout-minutes(60 kept, 15 dropped)hypatia-scan.yml:timeout-minuteson a reusable-caller job (illegal key → whole file parse-dead)generator-generic-ossf-slsa3-publish.yml: same illegal key on the SLSA provenance caller jobProof (branch
probe/actions-lockfile)startup_failure, 0 jobsstartup_failuresince 07-27First successful workflow runs in this repository since 2026-07-27.
Notes for the estate sweep
gh actions-lockbut still required by enforcement — they need a hand-added empty entry.gh actions-lockinserts its marker at line 1, displacing SPDX headers — swap them back or the linter fails.startup_failureregisters no check run); expect honest reds to surface on main after this merges — those are content failures to fix forward, not lockfile issues.🤖 Generated with Claude Code