fix(ci): relock dtolnay/rust-toolchain@stable — upstream ref moved - #353
Merged
Conversation
Every Rust-touching workflow fails at startup with: Lockfile pin 4cda84d5c5c54efe2404f9d843567869ab1699d4 for `dtolnay/rust-toolchain` does not match ref `stable` `stable` is a moving ref: dtolnay re-points it at each Rust release, so a lockfile pin against it goes stale on upstream's schedule rather than ours. Upstream now resolves to 4360b52568e2003a75bf9bc1d59f33a8e3fc893c. Blast radius while stale: Cargo Audit, MVP Smoke, Server Boot Gate, Live Provers, Rust CI, S4 Loop, Chapel CI, Formal Verification — all fail before running a step, on main and on every PR. `gh actions-lock --relock` alone does NOT fix it: a plain --relock leaves pins whose recorded commit is no longer reachable upstream as errors. --accept-moved is required to re-resolve them. Two side-effects of the tool were reverted rather than committed: - it re-inserted its "managed by gh actions-lock" marker at line 1 of all 31 workflows, duplicating the existing marker and displacing the SPDX identifier from line 1, which the Workflow Security Linter requires (it greps head -1). Deduped; SPDX restored to line 1. - it added a lockfile entry for main-estate-audit.yml, an untracked scratch file that is not part of the repository. Removed. Result is a one-line change. This recurs whenever upstream moves `stable`; the durable fix is either pinning a released tag instead of a moving ref, or a scheduled relock. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
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
1 participant
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.
Every Rust-touching workflow currently fails at startup, on
mainand on every PR:stableis a moving ref — dtolnay re-points it at each Rust release — so a lockfile pin against it goes stale on upstream's schedule, not ours. Upstream now resolves to4360b525….Affected while stale: Cargo Audit, MVP Smoke, Server Boot Gate, Live Provers, Rust CI, S4 Loop, Chapel CI, Formal Verification — all fail before running a step.
Worth knowing for the estate sweep
gh actions-lock --relockalone does not fix this. A plain--relockleaves pins whose recorded commit is no longer reachable upstream as errors;--accept-movedis required to re-resolve them.Two tool side-effects were reverted rather than committed:
managed by gh actions-lockmarker at line 1 of all 31 workflows — duplicating the marker already at line 2 and displacing the SPDX identifier, which the Workflow Security Linter requires on line 1 (it grepshead -1). Deduped and restored.main-estate-audit.yml, an untracked scratch file that is not part of the repository. Removed.The result is a one-line diff.
Recurrence
This will happen again every time upstream moves
stable. The durable fix is either pinning a released tag instead of a moving ref, or scheduling a periodic relock. Not done here — this PR restores CI and nothing more.Split out of #352 (documentation refresh) deliberately: that PR changes no CI behaviour, and this one changes nothing but.
🤖 Generated with Claude Code