Say what the rust-toolchain pin is, not a tag that moves under it - #939
Conversation
`dtolnay/rust-toolchain` publishes exactly one tag — `v1` — and moves it. We pinned 6c977a6c on 2026-09-10 in #859, when v1 pointed there; upstream re-pointed v1 to 02cb101e two days later. The sha is unchanged and still correct, but `# v1` had become a claim about a tag that no longer resolves to it, which is what zizmor's ref-version-mismatch reports. Nothing was out of sync through neglect. Dependabot maintains these comments on its own PRs, and dependabot-sync-actions-comments.yml repairs drift after workflow-file pushes; neither covers an upstream tag move, which happens with no push on our side and leaves the comment accurate about the tag while making it wrong about the sha. A version comment cannot stay true for an upstream that publishes only a moving tag, so these six stop claiming one. The comment now records what we actually pinned and when, plus why there is no version to name. Chosen over a zizmor ignore deliberately: an ignore would blind ref-version-mismatch at these six sites permanently, including against a genuine mismatch later. This keeps the audit live everywhere. Verified with the same online audit CI runs — zizmor 1.30.0 reports 0 findings and exits 0, against 6 medium and exit 13 before. actionlint clean. The sync bot skips these lines rather than rewriting them: its PIN_LINE_RE requires a `v?\d…` comment token, which prose does not match.
github-actions
Bot
added
the
github-actions
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. |
Sensitive Change Detection (shadow mode)This PR modifies control-plane files:
|
There was a problem hiding this comment.
Copilot review overview
🟢 Approved
The comments accurately describe the immutable pin, avoid bot rewrites, and leave workflow behavior unchanged.
Review effort: Balanced
Findings: None
What changed in this PR
Updates six Rust toolchain action comments to accurately document the immutable SHA without claiming the moving v1 tag.
Changes:
- Replaces stale
# v1annotations across Rust workflows. - Preserves all action SHAs and runtime behavior.
[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or rungh pr ready --undo.
Click "Ready for review" or rungh pr readyto reengage.
| File | Description |
|---|---|
.github/workflows/test.yml |
Corrects the Rust setup pin comment. |
.github/workflows/security.yml |
Corrects the cargo-deny toolchain pin comment. |
.github/workflows/release-rust.yml |
Corrects three release toolchain pin comments. |
.github/workflows/codeql.yml |
Corrects the CodeQL Rust toolchain pin comment. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Main is red on
GitHub Actions audit(zizmor), six findings, allref-version-mismatch, all the same action at the same sha:What actually happened
dtolnay/rust-toolchainpublishes exactly one tag —v1— and moves it. We pinned6c977a6con 2026-09-10 in #859, whenv1pointed there. Upstream re-pointedv1to02cb101eon 09-12, two days later.The sha is unchanged and still correct. What went stale is the comment's implicit claim that
v1resolves to it.Why no machinery caught it
Nothing was neglected — this case falls outside all of it:
cooldown: default-days: 10, weekly Monday, and the move is 8 days old.dependabot-sync-actions-comments.ymlrepairs drift after workflow-file pushes. It ran on 09-19 at5a6bd81and reported "all action pin comments are in sync" — correctly, by its own question, which is whether the comment names the tag we pinned from.For an upstream that publishes only a moving tag, a version comment cannot stay true. These six are the only pins of 172 in that position — the other 166 name immutable versions (
v4.2.2,v1.321.0, and so on) and are unaffected.The change
The six comments stop claiming a version and record what was actually pinned, and why there is no version to name.
Why not a zizmor ignore
An inline
# zizmor: ignore[ref-version-mismatch]would have matched the 19 ignores already in these workflows, and it was the first instinct. It is worse: it blinds the audit at those six sites permanently, including against a genuine mismatch introduced later. This keepsref-version-mismatchlive everywhere.Verification
Run locally with the same online audit CI uses:
No functional change — the sha, and therefore the toolchain every job installs, is untouched.
The sync bot will skip these lines rather than rewrite them: its
PIN_LINE_RErequires av?\d…comment token, which prose does not match. When dependabot eventually bumps the sha it may restore a# v1comment, which would reintroduce the finding; if that happens the durable answer is the same shape as this one.Follow-up, tracked separately: whether
actions-rust-lang/setup-rust-toolchain(immutable version tags, built-in caching) is a better fit for these six call sites than a minimal rustup wrapper. Evaluating on merits; not a release blocker.Summary by cubic
Replaces the
# v1comments on sixdtolnay/rust-toolchainpins with a note that records the pinned sha and explains that the upstreamv1tag moves, keeping the GitHub Actions audit free ofref-version-mismatchfindings. The sha is unchanged, so toolchain versions are unaffected.Written for commit abe7c42. Summary will update on new commits.