Repository navigation
governance / Actions lockfile verify is red on every PR: #810 bumped 7 actions without refreshing actions.lock #818
Description
Summary
governance / Actions lockfile verify fails on every pull request against
main. The cause is not on any PR: #810 (0157a9b chore(deps): bump the actions group with 7 updates) bumped action versions in five workflows without
refreshing .github/workflows/actions.lock, so the lock and the workflows now
disagree.
This is a pre-existing red that every contributor now has to learn to ignore,
which is the failure mode worth avoiding.
Measured
Diagnosed by fetching the actual gate scripts from hyperpolymath/standards
at the SHA CI pins (874ffe5839095bd9b181eb465ec20fb473cda7c5) and running them
against the tree, rather than reimplementing the check.
gh actions-lock v0.1.6 reports valid: false with these findings:
| Workflow | Action | In workflow | In actions.lock |
Category |
|---|---|---|---|---|
build-gossamer-gui.yml |
taiki-e/install-action |
v2.87.15 |
v2.87.13 |
ref-changed, stale |
ci.yml |
taiki-e/install-action |
v2.87.15 |
v2.87.13 |
ref-changed, stale |
codeql.yml |
github/codeql-action |
1c5b675653bb5c22dbe9b12b556ec555138e09fd |
b96794f015dfd88f77b49b1c93e0fa7110f94c63 |
ref-changed |
quality.yml |
ruby/setup-ruby |
v1.324.0 |
v1.323.0 |
ref-changed, stale |
release.yml |
docker/setup-buildx-action |
v4.4.1 |
v4.4.0 |
ref-changed, stale |
⚠ A local run is not evidence here. Verifying against a stale
origin/main returns rc=0 / valid: true — the same CLI version, the same
script — because CI checks out the PR merge commit against current
main while a stale remote-tracking ref compares a clone to its own last
fetch. git fetch before asserting anything about main.
⚠ The remediation message names a file that does not exist here
The gate prints:
Regenerate with
scripts/update-actions-lock.sh
There is no scripts/update-actions-lock.sh in this repository. The script
lives in hyperpolymath/standards and is copied into $RUNNER_TEMP by the
reusable workflow. Following the gate's own advice fails.
Acceptance criteria
-
.github/workflows/actions.lockregenerated so the five entries above
match what the workflows actually pin. - Regenerated in generate mode only. Never fix/rewrite mode — it has
previously de-pinned 24 SHAs to tags and invented invalid
uses: $/.github/actions/...refs, which startup-kill a workflow. -
git diffon the lock inspected before staging, and the change confirmed
to be only these five version/SHA fields — no entry added, removed or
re-pointed. -
governance / Actions lockfile verifygreen on the PR that lands it, and
still green on a subsequent unrelated PR (proving the fix is onmain,
not an artefact of that PR's merge commit). - ⚠
validate-spdx.shstaged mode has no extension filter, the known trap
for any commit touchingactions.lock. Run.githookslocally before
pushing. - Either raise the wrong-path remediation message upstream in
standards,
or open an issue there — a gate whose own instructions cannot be followed
teaches people to ignore it.
Not in scope
Bumping the lock entries to versions newer than the workflows pin. The lock
must describe what the workflows do, not lead them.
Activity
fix(ci): complete the Idris2 support install so abi-codegen-drift can…
fix(ci): remove the duplicate 'with:' block from six workflows (#822) (…
hyperpolymath commentedon Sep 22, 2026
Final acceptance criterion discharged — the lock gate is green on an unrelated PR
This issue required that
governance / Actions lockfile verifybe still green on a subsequent unrelated PR, proving the fix is onmainrather than an artefact of #823's own merge commit. That control has now run.#824 (
fix(ci): remove the duplicate 'with:' block from six workflows) was chosen deliberately as the control because it:uses:line — verified, zerouses:lines appear in its diff;actions.lockat all;Result on #824 @
9de66da:Merged as
54f14da. The lockfile fix is onmain.Full record for this issue
main@033193c, beforevalid: false, 25 findings, 11 errors across 7 workflowsvalid: true, 4 findings, 0 errorsgovernance / Actions lockfile verifysuccess (it wasfailureonmain)The 4 remaining findings are pre-existing warnings, left alone on purpose: 2×
sha-as-refoncodeql.yml, and 2×ref-movedondogfood-gate.yml'shyperpolymath/deed-ecosystem@mainandk9-ecosystem@main(not relocked —--relock/--accept-movedsilently bump@mainrefs).Two departures from this issue's text, both deliberate
security-policy.ymlandtests.ymldrifted after filing. Every criterion was re-measured against the tree rather than implemented from the text.dependencies:entries were removed, each cleared by evidence (five had a surviving same-commit twin; three were referenced by nouses:in any of the 32 workflows). That criterion was written against the fix-mode corruption trap; restoring the entries to satisfy its letter would ship a lockfile the tool still warns about. Full reasoning in chore(ci): refresh actions.lock so the lockfile gate goes green (#818) #823's body.Residue
DEBT-REGISTERCI-1 andCLAUDE.mdKnown Gap 4 blame Rust CI on the staledtolnay/rust-toolchain@stablepin that #823 removed. That attribution is wrong and remains wrong — the Rust failure is thetestcontainersversion conflict, which is #814. Confirmed directly in #824's newly-running jobs. The ledger entries still need amending against #814.Separately, #825 records that
dtolnay/rust-toolchain@v1is a mutable tag at 22 sites, and asks for the pinning mechanism to be decided and applied uniformly rather than piecemeal.🤖 Generated with Claude Code
https://claude.ai/code/session_0113HQM9LVGkNCzU1WwkJZSV