You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(ci): unbreak workflow YAML and add a complete actions.lock
Remediates GitHub Workflow Dependency Locking (public preview), which
rejects runs at startup_failure with zero jobs and no logs. See
hyperpolymath/standards#657.
Five steps, in order, because each blocks the next:
1. Unbroke any workflow whose `permissions:` carried a scalar with an
indented mapping under it - blind-permissions-insertion damage. This
matters beyond the one file: gh actions-lock refuses to run when ANY
workflow in the repo fails to parse, so the repo could never acquire a
lockfile and could never self-heal.
2. Repinned hyperpolymath/standards reusables off commits that have no
actions.lock. The rejection requires the CALLEE to be covered at the
pinned SHA, which is unsatisfiable at a pre-lockfile commit.
3. Generated the lockfile with gh actions-lock.
4. Hand-added the reusable-workflow caller entries the tool omits, as
'<path>': []. Measured across 218 repos: P(startup_failure | has
lockfile) = 91.7% vs 15.8% without, because every workflow a lockfile
OMITS is rejected. A PARTIAL lock is worse than none - running
gh actions-lock and stopping there is how this outage spread.
5. Restored SPDX-License-Identifier to line 1, which the tool displaces
with its own banner and which the workflow-security linter greps with
head -1.
Verified before push: 0 unparseable workflows, lockfile covers every
workflow with no omissions, SPDX on line 1 in every file.
Proven on hyperpolymath/anamnesis: 6 of 6 workflows dead -> 0
startup_failure, 13 running.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments