fix(ci): adopt the Actions lockfile — every workflow was startup_failure - #40
Merged
Conversation
All 27 workflows here return startup_failure: not failing, never starting.
Workflow-lockfile enforcement is active on this account and this repository had
no .github/workflows/actions.lock, so every workflow was rejected before any
job was created — no log, no check run, and no row in `gh pr checks`.
That also explains what looked like a separate problem. The branch rules here
require `CodeQL` and `openssf-compliance`, and neither ever reported, so both
appeared to be PHANTOM requirements naming checks that do not exist. They are
not: the rules are correct and every workflow was dead. Rewriting them would
have converted "these checks are broken" into "these checks are not required".
Applied the four-step cure proven across this campaign. The order matters
because each step's failure is invisible until the previous one is fixed:
1. gh actions-lock generates the lockfile and normalises pins to tags.
(It also reported 12 actions pinned to a bare SHA with no tag ref.)
2. Hoist SPDX back to line 1 — actions-lock inserts its own banner there and
the workflow linter requires SPDX first, so the tool that cures the
startup failures would otherwise redden all 27 workflow files.
3. Hand-author an empty [] lockfile entry for each of the 6 reusable-workflow
callers. gh actions-lock SKIPS callers, so without this they remain
startup_failure while everything else goes green — which reads as a
partial fix rather than a missing step.
4. Re-pin those callers to standards bd0df9ead7fa.
Verified: all 27 workflows parse, SPDX is on line 1 of each, and the lockfile
carries 6 caller entries.
EXPECT PREVIOUSLY-UNSEEN FAILURES. Nothing here has been checked in a long
time, so the first green run is a starting point rather than a result.
Found by the estate CI/CD census (hyperpolymath/standards#583), which pairs
what each repository REQUIRES against what it actually EMITS.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.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.
All 27 workflows here return
startup_failure: not failing, never starting.Workflow-lockfile enforcement is active on this account and this repo had no
.github/workflows/actions.lock, so every workflow was rejected before any job was created — no log, no check run, no row ingh pr checks.It also explains what looked like a separate problem
The branch rules here require
CodeQLandopenssf-compliance, and neither ever reported — so both appeared to be phantom requirements naming checks that do not exist.They are not. The rules are correct and every workflow was dead. Rewriting them would have converted "these checks are broken" into "these checks are not required".
The cure, in order
Each step's failure is invisible until the previous one is fixed:
gh actions-lock— generates the lockfile, normalises pins to tags (it also flagged 12 actions pinned to a bare SHA with no tag ref)actions-lockputs its banner there and the linter requires SPDX first, so the cure would otherwise redden all 27 files[]lockfile entries for the 6 reusable callers —actions-lockskips callers, so without this they staystartup_failurewhile everything else goes greenbd0df9ead7faVerified: all 27 workflows parse, SPDX on line 1 of each, 6 caller entries in the lockfile.
Expect previously-unseen failures. Nothing here has been checked in a long time — the first green run is a starting point, not a result.
Found by the estate CI/CD census (hyperpolymath/standards#583).
🤖 Generated with Claude Code