Repository navigation
chore(ci): apply the official actions.lock refresh candidate - #501
Conversation
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
|
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
 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Codex Review Summary: ✅ CompletedThis 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. |
|
Summary
The Workflow Security Linter refresh and the committed
actions.lockproduced 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 reportsclose-lock: 0 dangling refs,prune-stale: oracle vetoes 0andactions.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 astalefinding when the workflow calls that exactowner/repo/.github/workflows/…@ref. The governance log ond98b0e2shows 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 to55ffcc9. This form passed governance on453fe3b(#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
Generated by Claude Code