ci(rust-ci): pin the toolchain instead of tracking stable#89
Merged
Conversation
Every build, lint and test job installed `stable`, so the toolchain moved on its own the day upstream shipped a release -- and every consumer's open pull requests went red at once for a change nobody made. That happened on 2026-07-07: Rust 1.97.0 landed, widened clippy's question_mark lint to reach code that had been fine for months, and with `-D warnings` it was fatal. Every open PR in podup was red on Format & lint regardless of what it touched, blocking a security fix and a release until the lint was fixed. Nobody had upgraded anything. Add a `toolchain` input, defaulting to the pin, and use it in all seven jobs that were on `stable`. The MSRV job keeps its own `msrv` input -- that is the floor a user needs, a separate question from which toolchain CI builds with. Inputs go through `env:` rather than shell interpolation, matching rust-fuzz and the MSRV step. This is the same fix v1.8.0 applied to python-ci's ruff/pytest pins, for the same reason, on the lane that missed it. Adoption is a no-op today: `1.97` resolves to rustc 1.97.0 (2d8144b78), which is exactly what CI already runs, so consumers change compiler on their own schedule -- bump this pin via a new release, see which lints you gained, fix them deliberately. Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.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
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 build, lint and test job installed
stable, so the toolchain moved on its own the day upstream shipped a release — and every consumer's open PRs went red at once for a change nobody made.That is not hypothetical. Rust 1.97.0 landed on 2026-07-07, widened clippy's
question_marklint to reach code that had been fine for months, and-D warningsmade it fatal. Every open PR in podup was red on Format & lint regardless of what it touched — blocking a security fix (the release-key rotation) and a release, until the lint was fixed in podup#1008. Nobody had upgraded anything.Adds a
toolchaininput defaulting to the pin, used by all seven jobs that were onstable:stable${{ inputs.toolchain }}${{ inputs.msrv }}The MSRV job keeps its own input — the floor a user needs to compile is a separate question from which toolchain CI builds with. Inputs go through
env:rather than shell interpolation, matchingrust-fuzzand the existing MSRV step (the v1.7.0 hardening).This is the same fix v1.8.0 gave python-ci's ruff/pytest pins, for the same stated reason — "an unpinned ruff would change lint/test behaviour for every Python consumer the day a new release ships, with no per-repo buffer" — applied to the lane that missed it.
Adoption is a no-op today.
1.97resolves torustc 1.97.0 (2d8144b78 2026-07-07), which is exactly what CI already runs — verified locally against the same hash in podup's failing job log. Consumers get the compiler they already have, and stop drifting. Bump the pin via a new.githubrelease so each repo adopts a new toolchain deliberately, sees which lints it gained, and fixes them on its own schedule.Wants a v1.9.0 release after merge, then a pin bump in the Rust consumers.