Skip to content

fix(ci): prune stale entries from actions.lock with gh-actions-lock v0.2.0 - #495

Merged
hyperpolymath merged 4 commits into
mainfrom
claude/relock-after-491
Nov 10, 2026
Merged

hyperpolymath merged 4 commits into
mainfrom
claude/relock-after-491

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Summary

governance / Actions lockfile verify fails on main (d98b0e2). Every open PR fails it too, including #490 and #492.

The governance gate installs gh-actions-lock v0.2.0. That version reports unused lockfile entries as errors (upstream github/gh-actions-lock#159). echidna's lockfile has 8 such entries:

  • job-level reusable-workflow calls in governance, hypatia-scan, mirror, scorecard, secret-scanner, security-scan, spark-theatre-gate and the SLSA publish workflow (standards, proven-cicd, panic-attack, slsa-github-generator);
  • the deleted boj-build.yml.

The lockfile does not track reusable workflows. Each one stays SHA-pinned inline in its workflow file, which workflow-linter checks.

Changes

  • .github/workflows/actions.lock only. I regenerated it with gh-actions-lock v0.2.0, built from github/gh-actions-lock at tag v0.2.0, with --no-onboard --no-narrow.
  • No workflow file and no step pin changes. A plain gh actions-lock run 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

  • No secrets, credentials, or .env files included

Testing

  • Before the change: gh-actions-lock --verify-local gives "8 of 34 workflows failed: 8 stale", the same entries as the CI failure.
  • After the change: "All 34 workflows have complete lockfile coverage."
  • The run printed "could not verify" warnings for some pins, because the tool's GraphQL calls are blocked in this session. Those pins are unchanged, and the runner re-checks them at job start.

Generated by Claude Code

…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
@coderabbitai

coderabbitai Bot commented Nov 10, 2026 •

Copy link
Copy Markdown
Contributor

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters: 1

  • .github/workflows/actions.lock is excluded by !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

Run configuration

  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: 74aec588-e180-47be-a3e7-870a7a053348

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

@linear-code
linear-code Bot marked this pull request as ready for review November 10, 2026 18:18
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Nov 10, 2026 •

Copy link
Copy Markdown
Codex Review Summary: ❌ Failed

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-11-10T18:55:02.040914Z 392aafb New commits
🔒 Security Review ❌ Failed 2026-11-10T18:53:10.235547Z
We couldn’t complete this review. Comment @codex security review to try again.
392aafb New commits
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@hyperpolymath
hyperpolymath enabled auto-merge (squash) November 10, 2026 18:36
#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
@chatgpt-codex-connector

Copy link
Copy Markdown

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.

@hyperpolymath
hyperpolymath marked this pull request as draft November 10, 2026 18:50

Copy link
Copy Markdown
Owner Author

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, scripts/update-actions-lock.sh (verify_lock_coverage), says that gh-actions-lock v0.1.6 and v0.2.0 do not recognise reusable-workflow uses: paths. It also says that GitHub's startup enforcement still requires callers to carry the reusable repository and its transitive actions in actions.lock. So the gate accepts stale findings on purpose when the workflow names that exact reusable dependency.

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: security-scan.yml used panic-attack 55ffcc9 while the lockfile had be6ac46. #496 has already fixed that, and the gate passes on main.

I recommend closing this PR.


Generated by Claude Code

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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': []

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@hyperpolymath
hyperpolymath marked this pull request as ready for review November 10, 2026 18:53
@chatgpt-codex-connector

Copy link
Copy Markdown

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.

@hyperpolymath
hyperpolymath enabled auto-merge (squash) November 10, 2026 18:53
@chatgpt-codex-connector

Copy link
Copy Markdown

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.

@sonarqubecloud

Copy link
Copy Markdown

@hyperpolymath
hyperpolymath merged commit 03f03fb into main Nov 10, 2026
71 checks passed
@hyperpolymath
hyperpolymath deleted the claude/relock-after-491 branch November 10, 2026 18:57
hyperpolymath added a commit that referenced this pull request Nov 10, 2026
## 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>
hyperpolymath pushed a commit that referenced this pull request Nov 10, 2026
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
hyperpolymath added a commit that referenced this pull request Nov 10, 2026
## 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants