Repository navigation
standards needs its own .github/workflows/actions.lock — lockfile enforcement 0s-startup-fails every downstream reusable caller #573
Description
Problem
GitHub's workflow-lockfile enforcement now rejects runs as 0-second startup_failures (no jobs, no logs, no check runs — error only on the run HTML page) for workflows that aren't covered by .github/workflows/actions.lock.
Repos have been cured individually with gh actions-lock (proven: echidna #341, haec #46, and today Invisible-Door-Studios/chronicles-of-slavia#59 — 10+ workflows went from 0s startup_failure to green in one commit).
But workflows that call this repo's reusables cannot be cured downstream. On chronicles-of-slavia, after its lockfile landed, exactly the seven reusable-caller workflows still 0s-fail:
- rust-ci, governance, secret-scanner, scorecard, mirror, hypatia-scan, boj-build — all
uses: hyperpolymath/standards/.github/workflows/*@412a703…
The enforcement needs the called repo to carry its own lockfile before caller runs can start. Until standards ships one, every downstream wrapper in the estate (~6 reusables × dozens of repos) stays dead regardless of per-repo remediation.
Fix
gh extension install github/gh-actions-lock # if not present
gh actions-lock # in this repo; commit the result
Gotchas from the estate remediation memory: verify no dtolnay/rust-toolchain refs get semver-narrowed (dtolnay reads the toolchain from the REF), and if an SPDX-header linter checks line 1, move the # This workflow is managed by gh actions-lock. marker to line 2 (it inserts itself as line 1; chronicles hit exactly this, fixed in Invisible-Door-Studios/chronicles-of-slavia@1d0dffd).
🤖 Generated with Claude Code
Activity
hyperpolymath commentedon Aug 4, 2026
Update from the chronicles-of-slavia remediation (Invisible-Door-Studios/chronicles-of-slavia#61): caller-side lockfile coverage for reusables IS achievable by hand — the enforcement accepts entries of the form
hyperpolymath/standards@<sha>in the caller'sworkflows:section, with auses:transitive list on the dependency entry naming every action the called reusables use at that ref (portable verbatim from this repo's own actions.lock). With that in place, Rust CI and Secret Scanner produced the first successful runs of their existence on the caller side.Two upstream items this surfaced:
governance-reusable.yml's embedded workflow-security linter is lockfile-unaware — it requires inline 40-hex SHAs on everyuses:and therefore fails any consumer that adoptedgh actions-lock(whose model is tag-form refs + lockfile-authoritative SHAs). Chronicles' local linter got a lockfile-aware pin check in fix(ci): adopt gh-actions-lock lockfile — cures repo-wide 0s startup_failure Invisible-Door-Studios/chronicles-of-slavia#59 (ref covered by actions.lock counts as pinned; subpaths normalized to repo level) — the same patch belongs in the reusable.gh actions-lockv0.1.6 does not model reusable-workflow deps at all (scans callers, reports nothing to pin) — worth an upstream feature request or an estate wrapper, since every consumer repo will need these hand-authored entries until then.hyperpolymath commentedon Aug 7, 2026
Closed — the premise no longer holds.
This issue states that
standardshas no.github/workflows/actions.lock, andthat this 0s-startup-fails every downstream reusable caller.
Re-measured 2026-08-07:
The lockfile exists (10,567 bytes, blob
f74064c3) and covers 38 workflowfiles.
standardsmainover the last 30 runs: 21 success, 2 failure,7 cancelled — not the zero-job startup-failure pattern this issue describes.
Landed via the lockfile adoption chain (#570 / #571 / #572 / #574).
The residual failures on
mainare separate defects with their own causes; theyare not "no lockfile", which is what this issue tracks.