Repository navigation
ci(actions-lock): record tag refs for SHA-keyed lock entries - #417
Conversation
The lock had drifted from the workflow files. GitHub refuses to start a workflow whose uses: set doesn't match its lock entries, and rejects a lock entry that records its own SHA as ref. - record `actions/cache@55cc8345863c…`: `ref:` changes from the SHA to `v6.1.0`, the tag that peels to the same commit - record `actions/checkout@3d3c42e5aac5…`: `ref:` changes from the SHA to `v7.0.1`, the tag that peels to the same commit - record `actions/upload-artifact@043fb46d1a93…`: `ref:` changes from the SHA to `v7.0.1`, the tag that peels to the same commit - record `erlef/setup-beam@54075bcc5e24…`: `ref:` changes from the SHA to `v1.24.1`, the tag that peels to the same commit - record `swatinem/rust-cache@6323deb102c3…`: `ref:` changes from the SHA to `v2.9.2`, the tag that peels to the same commit - record `webfactory/ssh-agent@e83874834305…`: `ref:` changes from the SHA to `v0.10.0`, the tag that peels to the same commit Each new record's commit was checked against the upstream tag with git ls-remote. No commit an existing entry pins was changed. Standards reusable pins are left as they are. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
|
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 SummaryThis 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. |
|
Add Carrot credits or activate Agent usage billing to use Autofix |
Summary
Six records in
actions.lockrecordedref:as their own commit SHA. GitHub's lockfile enforcement rejects that ("invalid lockfile pin"). standards#1271 fixed the same entries in standards' lock. No workflow file changes.Changes
Each record's
ref:changes from the SHA to the tag that peels to the same commit, checked withgit ls-remote.commit,owner_idandrepo_idare unchanged.actions/cache@55cc8345…→v6.1.0actions/checkout@3d3c42e5…→v7.0.1actions/upload-artifact@043fb46d…→v7.0.1erlef/setup-beam@54075bcc…→v1.24.1swatinem/rust-cache@6323deb1…→v2.9.2webfactory/ssh-agent@e8387483…→v0.10.0Left as is:
dtolnay/rust-toolchain@6c977a6c…. No tag peels to that commit, and it is only reached through the standards record.Testing
scripts/check-lock-sync.shpasses.Not fixed here
The standards reusables stay at
571cc734. Re-pinning them to a current standards commit makes governance, hypatia-scan and secret-scanner fail at startup with zero jobs; I tested that on hyperpolymath/presswerk#138. That has to be fixed in standards.Generated by Claude Code