Repository navigation
ci(actions-lock): bring actions.lock back in line with the workflows - #89
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. - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `haskell-actions/setup@v2.12.1` (the workflow already uses `v2.12.1`) - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `hyperpolymath/smtp-notify-action@v0.5.0` (the workflow already uses `v0.5.0`) - new record `haskell-actions/setup@v2.12.1` (ref `v2.12.1`, commit `0f8e8c99d88a…`) - new record `hyperpolymath/smtp-notify-action@v0.5.0` (ref `v0.5.0`, commit `c1c9fa07992a…`) - remove the record `haskell-actions/setup@v2.12.0`, which no entry references any more - remove the record `hyperpolymath/smtp-notify-action@v0.3.0`, which no entry references any more 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. |
Summary
actions.lockhad drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and GitHub refuses to start a workflow whoseuses:set doesn't match its lock entries. No workflow file changes.Changes
casket-pages.yml:haskell-actions/setup@v2.12.0→@v2.12.1push-email-notify.yml:hyperpolymath/smtp-notify-action@v0.3.0→@v0.5.0Each new record's commit was checked against the upstream tag with
git ls-remote. No commit an existing entry pins was changed.Testing
scripts/check-lock-sync.shreports no mismatch except thehyperpolymath/standardsreusable refs, which this PR leaves alone.Not fixed here
The standards reusables stay red. Re-pinning them to a current standards commit makes them fail at startup with zero jobs; I tested that on hyperpolymath/presswerk#138. That has to be fixed in standards.
Generated by Claude Code