Repository navigation
ci(actions-lock): record a tag ref for the SHA-pinned checkout entry - #138
Merged
Merged
Conversation
Every job in the standards reusables (governance, hypatia, secret-scanner, mirror, rust-ci, scorecard) failed at setup with "Unable to resolve action actions/checkout@3d3c42e5...: invalid lockfile pin". GitHub checks a reusable's actions against the lockfile of the repo that defines it. standards' lock at the old pins recorded those SHA-pinned actions with `ref:` set to the SHA, which the runner rejects. standards#1271 corrected that to tag refs (same commits); these pins predate it. - Re-pin the standards reusables to standards main (1fdc61c0) with standards' scripts/propagate-workflow-pins.sh, and relock with scripts/relock-standards-pin.sh. The lock now records metadatastician/standards@1fdc61c0 and every action those reusables use. - Repair leftover lock drift so standards' scripts/check-lock-sync.sh passes: entries for versions the workflows no longer use, missing entries for the versions they do, and any leaf entry whose `ref:` was its own SHA. Each new record's commit was checked against the upstream tag with git ls-remote. No commit an existing entry pins was changed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
Contributor
|
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
 |
| Layer / File(s) | Summary |
|---|---|
Update reusable-workflow pins .github/workflows/*.yml |
The governance, Hypatia, mirror, Rust CI, scorecard, and secret-scanner jobs now reference the same updated commit. The secret-scanner job’s permissions and inherited secrets remain unchanged. Hypatia continues to inherit secrets. |
Priority:
Estimated code review effort: 2 (Simple) | ~8 minutes
Change: Bug fix
Possibly related issues
hyperpolymath/reposystem#319— The PR updates six reusable-workflow pins, which matches the issue’s stale-caller-pin objective. The supplied changes do not show updates toactions.lock.
Suggested reviewers: metadatastician
Merge Risk: 
21723
-
No actionable merge-blocking risk was found in these reusable-workflow pin updates.
Pre-merge checks: 
-
Check name Status Explanation Title check The title clearly identifies the CI lockfile change and the re-pinning of standards reusable workflows. Description check The description directly explains the lockfile failure, the workflow re-pinning, the checkout reference correction, and the reported tests. Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request.
- 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.
Comment @coderabbitai help to get the list of available commands.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
The re-pin to standards@1fdc61c0 turned governance, hypatia-scan, secret-scanner and rust-ci into startup failures (zero jobs, no check run). Those reusables currently fail to load from callers at recent standards commits, as recorded in odds-and-sods-package-manager's governance.yml and secret-scanner-vendored.yml. That needs fixing in standards, not here, so this reverts the six workflow pins and the lock to main. What stays: the lock entry for actions/checkout@3d3c42e5 recorded `ref: '3d3c42e5...'`, which the runner rejects ("invalid lockfile pin"), and broke codeql.yml. It now records `ref: 'v7.0.1'`, the tag that peels to the same commit (git ls-remote), as standards#1271 did for its own lock. CodeQL passed on the previous push with this entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
hyperpolymath
changed the title
This was referenced Oct 27, 2026
Merged
Merged
Merged
Merged
Merged
Merged
Merged
Merged
hyperpolymath
enabled auto-merge (squash)
October 27, 2026 01:35
Contributor
|
Add Carrot credits or activate Agent usage billing to use Autofix |
hyperpolymath
disabled auto-merge
October 27, 2026 01:59
hyperpolymath
added a commit
to hyperpolymath/bunsenite
that referenced
this pull request
Oct 27, 2026
## Summary `generator-generic-ossf-slsa3-publish.yml` calls `slsa-framework/slsa-github-generator@f7dd8c54…` as a job-level reusable, but `actions.lock` had neither an entry nor a record for it. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `generator-generic-ossf-slsa3-publish.yml`: add the missing entry `slsa-framework/slsa-github-generator@f7dd8c54c2067bafc12ca7a55595d5ee9b75204a` - New record for it: `ref: 'v2.1.0'`, `owner_id: 80431187`, `repo_id: 475074978`. That is the tag `git ls-remote` shows peeling to `f7dd8c54`, and the IDs seven other estate lockfiles record for this action. ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (governance, hypatia-scan, secret-scanner, rust-ci) stay red. At the pins on `main` they fail with "invalid lockfile pin" from standards' own old lockfile. Re-pinning to a current standards commit makes them fail at startup with zero jobs instead; I tested that on hyperpolymath/presswerk#138. That has to be fixed in standards, so this PR doesn't touch those pins. --- _Generated by [Claude Code](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/ephapax
that referenced
this pull request
Oct 27, 2026
## Summary
Six records in `actions.lock` recorded `ref:` 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 with `git ls-remote`. `commit`, `owner_id` and
`repo_id` are unchanged.
- `actions/cache@55cc8345…` → `v6.1.0`
- `actions/checkout@3d3c42e5…` → `v7.0.1`
- `actions/upload-artifact@043fb46d…` → `v7.0.1`
- `erlef/setup-beam@54075bcc…` → `v1.24.1`
- `swatinem/rust-cache@6323deb1…` → `v2.9.2`
- `webfactory/ssh-agent@e8387483…` → `v0.10.0`
Left as is: `dtolnay/rust-toolchain@6c977a6c…`. No tag peels to that
commit, and it is only reached through the standards record.
## Testing
- standards' `scripts/check-lock-sync.sh` passes.
- Every lock entry has a dependency record.
## 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_
Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/jtv-lang
that referenced
this pull request
Oct 27, 2026
…122) ## Summary `actions.lock` had drifted from the workflow files. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `generator-generic-ossf-slsa3-publish.yml`: add the missing entry and record for `slsa-framework/slsa-github-generator@f7dd8c54…`, with `ref: 'v2.1.0'` and the IDs seven other estate lockfiles record for this action - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` (the version the workflow uses), with a new record and the old one removed Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here - The standards reusables (governance, hypatia-scan, secret-scanner) 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. - `coverage.yml`: no lock change was needed. If it is still blocked after this, the cause is something else. --- _Generated by [Claude Code](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/ideas-to-alphas
that referenced
this pull request
Oct 27, 2026
## Summary `release.yml` calls `slsa-framework/slsa-github-generator@f7dd8c54…` as a job-level reusable, but `actions.lock` had neither an entry nor a record for it. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `release.yml`: add the missing entry `slsa-framework/slsa-github-generator@f7dd8c54c2067bafc12ca7a55595d5ee9b75204a` - New record for it: `ref: 'v2.1.0'`, `owner_id: 80431187`, `repo_id: 475074978`. That is the tag `git ls-remote` shows peeling to `f7dd8c54`, and the IDs seven other estate lockfiles record for this action. ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (hypatia-scan, secret-scanner) stay red. At the pins on `main` they fail with "invalid lockfile pin" from standards' own old lockfile. Re-pinning to a current standards commit makes them fail at startup with zero jobs instead; I tested that on hyperpolymath/presswerk#138. That has to be fixed in standards, so this PR doesn't touch those pins. --- _Generated by [Claude Code](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/panic-attack
that referenced
this pull request
Oct 27, 2026
## Summary `release.yml`'s lock entry names `slsa-framework/slsa-github-generator@f7dd8c54…`, but `actions.lock` has no dependency record for it, so the lock has a dangling edge. standards' `relock-standards-pin.sh` refuses to touch a lock in that state. No workflow file changes. ## Changes - New record `slsa-framework/slsa-github-generator@f7dd8c54c2067bafc12ca7a55595d5ee9b75204a`: `ref: 'v2.1.0'` (the tag `git ls-remote` shows peeling to `f7dd8c54`), `owner_id: 80431187`, `repo_id: 475074978`. These are the IDs seven other estate lockfiles record for this action. ## Testing - standards' `scripts/check-lock-sync.sh` passes. - Every lock entry now has a dependency record. ## 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. - `cargo-audit`, `chapel-ci`, `coverage` and `e2e` needed no lock change. Earlier I listed them as blocked by the lock; if they still fail, the cause is something else. --- _Generated by [Claude Code](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/seamstress
that referenced
this pull request
Oct 27, 2026
…89) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `@v2.12.1` - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - New records for both, and the old records removed now that nothing references them Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone. - Every lock entry has a dependency record. ## 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/vcs-ircd
that referenced
this pull request
Oct 27, 2026
…131) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and the SLSA generator call was never locked. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. This blocked `release.yml`. No workflow file changes. ## Changes - `generator-generic-ossf-slsa3-publish.yml`: add the missing entry and record for `slsa-framework/slsa-github-generator@f7dd8c54…`, with `ref: 'v2.1.0'` and the IDs seven other estate lockfiles record - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: `actions/download-artifact@v8.0.1` → `@v8.0.2`, `actions/upload-artifact@v7.0.1` → `@v7.0.2` - New records for those refs, and the three old records removed now that nothing references them Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone. - Every lock entry has a dependency record. ## 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/iseriser
that referenced
this pull request
Oct 27, 2026
…137) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and the SLSA generator call was never locked. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `@v2.12.1` - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: add the missing entry for `slsa-framework/slsa-github-generator@f7dd8c54…` - New records for those three refs, and the two old records removed now that nothing references them. The SLSA record has `ref: 'v2.1.0'` and the IDs seven other estate lockfiles record for this action. Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (governance, hypatia-scan, secret-scanner) 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/nimiser
that referenced
this pull request
Oct 27, 2026
…89) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and the SLSA generator call was never locked. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `@v2.12.1` - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: add the missing entry for `slsa-framework/slsa-github-generator@f7dd8c54…` - New records for those three refs, and the two old records removed now that nothing references them. The SLSA record has `ref: 'v2.1.0'` and the IDs seven other estate lockfiles record for this action. Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (governance, hypatia-scan, secret-scanner) 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/tlaiser
that referenced
this pull request
Oct 27, 2026
…93) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and the SLSA generator call was never locked. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `@v2.12.1` - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: add the missing entry for `slsa-framework/slsa-github-generator@f7dd8c54…` - New records for those three refs, and the two old records removed now that nothing references them. The SLSA record has `ref: 'v2.1.0'` and the IDs seven other estate lockfiles record for this action. Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (governance, hypatia-scan, secret-scanner) 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/mylangiser
that referenced
this pull request
Oct 27, 2026
…95) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and the SLSA generator call was never locked. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `@v2.12.1` - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: add the missing entry for `slsa-framework/slsa-github-generator@f7dd8c54…` - New records for those three refs, and the two old records removed now that nothing references them. The SLSA record has `ref: 'v2.1.0'` and the IDs seven other estate lockfiles record for this action. Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (governance, hypatia-scan, secret-scanner) 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/lucidscript
that referenced
this pull request
Oct 27, 2026
… uses (#74) ## Summary `push-email-notify.yml` uses `hyperpolymath/smtp-notify-action@v0.5.0`, but `actions.lock` still recorded `v0.3.0`. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - New `v0.5.0` record (commit `c1c9fa07…`, checked against the upstream tag with `git ls-remote`), and the old `v0.3.0` record removed ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone. - Every lock entry has a dependency record. ## 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/llm-grace
that referenced
this pull request
Oct 27, 2026
…104) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and the SLSA generator call was never locked. GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. No workflow file changes. ## Changes - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: `actions/upload-artifact@v7.0.1` → `@v7.0.2`; add the missing entry for `slsa-framework/slsa-github-generator@f7dd8c54…` - `static-analysis-gate.yml`: `actions/download-artifact@v8.0.1` → `@v8.0.2`, `actions/upload-artifact@v7.0.1` → `@v7.0.2` - New records for `download-artifact@v8.0.2`, `smtp-notify-action@v0.5.0` and the SLSA generator (`ref: 'v2.1.0'`, with the IDs seven other estate lockfiles record), and the three old records removed now that nothing references them Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## RSR Quality Checklist ### Required - [x] No banned language patterns - [x] No secrets, credentials, or `.env` files included ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## 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](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/betlang
that referenced
this pull request
Oct 27, 2026
…139) ## Summary `actions.lock` had drifted from the workflow files. Dependabot bumped actions in the YAML without regenerating the lock, and GitHub refuses to start a workflow whose `uses:` set doesn't match its lock entries. This blocked `release.yml`, `casket-pages.yml` and `push-email-notify.yml`. No workflow file changes. ## Changes - `casket-pages.yml`: `haskell-actions/setup@v2.12.0` → `@v2.12.1` (the version the workflow uses) - `push-email-notify.yml`: `hyperpolymath/smtp-notify-action@v0.3.0` → `@v0.5.0` - `release.yml`: `actions/download-artifact@v8.0.1` → `@v8.0.2`, `actions/upload-artifact@v7.0.1` → `@v7.0.2` - New records for those four refs, and the four old records removed now that nothing references them Each new record's commit was checked against the upstream tag with `git ls-remote`. No commit an existing entry pins was changed. ## Testing - standards' `scripts/check-lock-sync.sh` reports no mismatch except the `hyperpolymath/standards` reusable refs, which this PR leaves alone (see below). - Every lock entry has a dependency record. ## Not fixed here The standards reusables (governance, hypatia-scan, secret-scanner) stay red. At the pins on `main` they fail with "invalid lockfile pin" from standards' own old lockfile. Re-pinning to a current standards commit makes them fail at startup with zero jobs instead; I tested that on hyperpolymath/presswerk#138. That has to be fixed in standards, so this PR doesn't touch those pins. --- _Generated by [Claude Code](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_ Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was wrong
codeql.ymlfailed at job setup:The lock entry for that SHA-pinned action recorded
ref: '3d3c42e5…', its own SHA, which the runner rejects. standards#1271 fixed the same entries in standards' lock.Changes
actions.lock: in theactions/checkout@3d3c42e5…entry,ref:changes from the SHA tov7.0.1. That tag peels to the same commit (checked withgit ls-remote), socommit,owner_idandrepo_idare unchanged. One line.Testing
On the first push of this branch,
analyze (actions, none)(CodeQL) passed. It failed with the error above onmain.Not fixed here, and why
The first push also re-pinned the six standards reusables to standards
main(1fdc61c0). That made governance, hypatia-scan, secret-scanner and rust-ci fail at startup with zero jobs, which is worse than the setup failure onmain. Those reusables currently fail to load from callers at recent standards commits, as recorded in odds-and-sods-package-manager'sgovernance.ymlandsecret-scanner-vendored.yml. So the second commit reverts the re-pin. That has to be fixed in standards. Onmainthose four workflows still fail with the old "invalid lockfile pin" from standards' lock at the commits they pin.🤖 Generated with Claude Code
https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye