Repository navigation
fix(ci): prune stale entries from actions.lock with gh-actions-lock v0.2.0 - #495
Conversation
…0.2.0 governance / Actions lockfile verify fails on main: 8 workflows have lockfile entries that no step `uses:` references. The governance gate installs gh-actions-lock v0.2.0, which reports unused entries as errors (upstream #159). The entries are job-level reusable-workflow calls (standards, proven-cicd, panic-attack, slsa-github-generator) and the deleted boj-build.yml. The lockfile does not track reusable workflows; each stays SHA-pinned inline in its workflow, which workflow-linter checks. Regenerated with gh-actions-lock v0.2.0 (built from github/gh-actions-lock at the v0.2.0 tag) using --no-onboard --no-narrow, so no workflow file and no step pin changes. `gh-actions-lock --verify-local`: all 34 workflows have complete lockfile coverage. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0136P7ZnmBahbhfkFEP6ark4
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters: 1
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including
|
Codex Review Summary: ❌ FailedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
#496 refreshed actions.lock on main. Take main's lockfile, then regenerate it with gh-actions-lock v0.2.0 --no-onboard --no-narrow, so the only change against main is removing the 8 reusable-workflow entries that v0.2.0 reports as unused. No workflow file changes; --verify-local: all 34 workflows have complete lockfile coverage. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0136P7ZnmBahbhfkFEP6ark4
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
|
Do not merge. I have turned off auto-merge and marked this PR as a draft. This PR's premise is wrong. The standards gate wrapper, The 8 entries this PR removes are those required entries, so removing them risks failing workflows at job start. The earlier red on main came from a real desync: I recommend closing this PR. Generated by Claude Code |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 15b21c00dd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - 'metadatastician/standards@a797d308c0517d4e2d21cc7f1cb08d41f82b1a12' | ||
| '.github/workflows/hypatia-scan.yml': | ||
| - 'metadatastician/standards@d3e4b485a2af90c92a8e18af0888cd19cb132cd9' | ||
| '.github/workflows/governance.yml': [] |
There was a problem hiding this comment.
Preserve reusable-workflow edges in the lock
When governance / Validate Hypatia Baseline scans this tree, .github/workflows/governance.yml still has a job-level uses: metadatastician/standards..., but this row now declares no dependency and the corresponding top-level record is also deleted. The repository's canonical lock chain intentionally completes these job-level refs transitively; without them Hypatia reports invalid_actions_lock/workflow_dependencies_missing, so the required governance check remains red even though raw gh-actions-lock --verify-local passes. Regenerate with the canonical wrapper or restore all eight reusable-workflow edges rather than pruning them.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
After the merge, main at 03f03fb does not show this. The governance and Hypatia checks pass there.
Main has 5 failures: 4 mirror / * jobs and scan / scan. The same 5 failed on the previous two main commits, cc5f566 and 453fe3b, before this PR. scan / scan gets past job start and builds the scanner. It then fails on verisimdb-data dispatch failed with HTTP 401, which is a credential problem, not a lockfile problem. So the reusable-workflow callers still start without the pruned entries.
Generated by Claude Code
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
|
This security review couldn’t start because the paying account has exhausted its Codex allowance and has insufficient available credits. The payer can check their balance and add credits in the Codex usage dashboard, then try again. If you do not manage the paying account, contact this repository's admins. |
|
## Summary hyperpolymath/proven-cicd is being retired. Its commits were merged into hyperpolymath/proven-cicd-and-workflows (proven-cicd-and-workflows#95). This PR moves the Secret Scanner call to the new repository before the owner deletes the old one. - Before: `hyperpolymath/proven-cicd/.github/workflows/secret-scanner-reusable.yml@a12b2b4` - After: `hyperpolymath/proven-cicd-and-workflows/.github/workflows/secret-scanner-reusable.yml@1fd5e63` (the merge of proven-cicd-and-workflows#94) a12b2b4 is an ancestor of 1fd5e63. The reusable workflow differs in 1 line: the caller check also admits `proven-cicd-and-workflows`. This call needs that line. ## actions.lock is not changed Since #495, the lock does not record job-level reusable-workflow calls: governance installs gh-actions-lock v0.2.0, which rejects those records as stale. The entry for `secret-scanner.yml` stays `[]`. The Workflow Security Linter refresh candidate (run 42889686324) still adds those records back: 149 lines, for this call and 7 other reusable calls. Applying it would undo #495 and turn governance red again, so this PR does not apply it. That refresh step and the governance gate now disagree; this is a separate defect for the owner. ## Test plan - [ ] Secret Scanner runs at the new pin and its caller check passes. - [ ] governance / Actions lockfile verify stays green. --- _Generated by [Claude Code](https://claude.ai/code/session_0136P7ZmAsYpFA9gxfQLF3F6)_ Signed-off-by: Claude <noreply@anthropic.com> Co-authored-by: Claude <noreply@anthropic.com>
Applied without edits from the "Prepare official actions.lock refresh candidate" step of run 42897428598 on 18828c3 (close-lock: 0 dangling refs; check-lock-sync: in sync). It restores the reusable-workflow records that #495 removed, for the 8 job-level reusable calls, with their transitive actions. #495 removed them as stale, but the governance gate accepts them: its verifier (standards a797d30, scripts/update-actions-lock.sh) accepts a stale finding when the workflow calls that exact owner/repo/...@ref. The failure #495 fixed was one record (security-scan.yml at panic-attack be6ac46, after #491 moved the call to 55ffcc9). With this commit the committed lock matches what the standards refresh tool writes, so a refresh no longer shows a diff. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0136P7ZmAsYpFA9gxfQLF3F6
## Summary The Workflow Security Linter refresh and the committed `actions.lock` produced different locks. This PR makes them agree, using the form the owner chose: the form that the standards refresh tool writes. The candidate is applied without edits, from the "Prepare official actions.lock refresh candidate" step of run 42897428598 on `18828c3`. That run reports `close-lock: 0 dangling refs`, `prune-stale: oracle vetoes 0` and `actions.lock is in sync`. It restores the reusable-workflow records that #495 removed: 8 job-level reusable calls, with their transitive actions. ## Why this is safe for governance #495 removed these records as stale. The governance gate accepts them, however. Its verifier (standards `a797d30`, `scripts/update-actions-lock.sh`, `verify_lock_coverage`) accepts a `stale` finding when the workflow calls that exact `owner/repo/.github/workflows/…@ref`. The governance log on `d98b0e2` shows that 7 of the 8 records were accepted. It rejected only 1: `security-scan.yml → panic-attack@be6ac46`, which was stale because #491 had moved the call to `55ffcc9`. This form passed governance on `453fe3b` (#496). The refresh run above printed the same "Accepted reusable-workflow lock coverage" line for each of the 8 current calls. ## Correction #500 said that applying this candidate would turn governance red. That was wrong, for the reason above. ## Test plan - [ ] governance / Actions lockfile verify passes on this head. --- _Generated by [Claude Code](https://claude.ai/code/session_0136P7ZmAsYpFA9gxfQLF3F6)_ Co-authored-by: Claude <noreply@anthropic.com>



Summary
governance / Actions lockfile verifyfails on main (d98b0e2). Every open PR fails it too, including #490 and #492.The governance gate installs
gh-actions-lockv0.2.0. That version reports unused lockfile entries as errors (upstream github/gh-actions-lock#159). echidna's lockfile has 8 such entries:governance,hypatia-scan,mirror,scorecard,secret-scanner,security-scan,spark-theatre-gateand the SLSA publish workflow (standards, proven-cicd, panic-attack, slsa-github-generator);boj-build.yml.The lockfile does not track reusable workflows. Each one stays SHA-pinned inline in its workflow file, which
workflow-linterchecks.Changes
.github/workflows/actions.lockonly. I regenerated it withgh-actions-lockv0.2.0, built fromgithub/gh-actions-lockat tagv0.2.0, with--no-onboard --no-narrow.gh actions-lockrun would also have rewritten 2 bare-SHA pins to refs, one of them to@main. I did not apply those rewrites.RSR Quality Checklist
Required
.envfiles includedTesting
gh-actions-lock --verify-localgives "8 of 34 workflows failed: 8 stale", the same entries as the CI failure.Generated by Claude Code