ci: pin the toolchain to 1.98.1 in all three jobs #54

fabi · 2026-09-17T20:22:09Z

fabi commented

2026-09-17 20:22:09 +00:00

Closes #15.

All three jobs resolved their toolchain with dtolnay/rust-toolchain@stable, so the gate's verdict depended on the date as much as on the tree. This pins the three refs to 1.98.1.

Why that version. It is what run 206 resolved, and docker/ci/Dockerfile already pins the same one — so docker/ci/run cargo clippy --workspace --all-targets -- -D warnings on a desktop is now a stand-in for this workflow rather than an approximation of it. That mattered concretely: collapsible_else_if is warn on 1.92.0 and allow-by-default pedantic on 1.98.1, which is how a clean local run and a red CI run were both correct, and what this issue was filed about.

Why not a rust-toolchain.toml. It would pin every cargo invocation on every machine, including hosts whose rustup would then download a second toolchain on the next build. The gate is a property of CI, and the desktops already have docker/ci for a faithful run.

The bump procedure is in the file, next to the pin: change the three refs here and the Dockerfile's FROM rust:<version>-bookworm in one commit, in its own PR, so that the lints a new version turns on are the diff under review rather than a surprise inside someone else's change.

Also in here, since it sits four lines away and states a number that has decayed twice: the corpus-report step's comment quoted 207/0/14 as the tally. It now describes the shape of the problem without a number.

Verification is this PR's own CI run — it exercises the pinned ref on all three jobs. @1.98.1 exists as a branch of the action (checked against the GitHub API), and nothing else in the workflow changed.

🤖 Generated with Claude Code

Closes #15. All three jobs resolved their toolchain with `dtolnay/rust-toolchain@stable`, so the gate's verdict depended on the date as much as on the tree. This pins the three refs to **1.98.1**. **Why that version.** It is what run 206 resolved, and `docker/ci/Dockerfile` already pins the same one — so `docker/ci/run cargo clippy --workspace --all-targets -- -D warnings` on a desktop is now a stand-in for this workflow rather than an approximation of it. That mattered concretely: `collapsible_else_if` is `warn` on 1.92.0 and `allow`-by-default pedantic on 1.98.1, which is how a clean local run and a red CI run were *both* correct, and what this issue was filed about. **Why not a `rust-toolchain.toml`.** It would pin every `cargo` invocation on every machine, including hosts whose rustup would then download a second toolchain on the next build. The gate is a property of CI, and the desktops already have `docker/ci` for a faithful run. **The bump procedure is in the file**, next to the pin: change the three refs here *and* the Dockerfile's `FROM rust:<version>-bookworm` in one commit, in its own PR, so that the lints a new version turns on are the diff under review rather than a surprise inside someone else's change. Also in here, since it sits four lines away and states a number that has decayed twice: the corpus-report step's comment quoted `207/0/14` as the tally. It now describes the shape of the problem without a number. **Verification is this PR's own CI run** — it exercises the pinned ref on all three jobs. `@1.98.1` exists as a branch of the action (checked against the GitHub API), and nothing else in the workflow changed. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

fabi added 1 commit 2026-09-17 20:22:10 +00:00

ci: pin the toolchain to 1.98.1 in all three jobs

CI / Native — linux (pull_request) Successful in 2h24m59s

Details

CI / WASM — Web (pull_request) Successful in 31m6s

Details

CI / Formatting (pull_request) Successful in 1m39s

Details

5efe69b4d6

All three jobs used `dtolnay/rust-toolchain@stable`, so the gate resolved to
whatever stable was on the day it ran. A floating lint gate is not a gate: the
same tree goes green or red by date, and that already produced a disagreement
between two people reading the same commit — `collapsible_else_if` is `warn` on
1.92.0 and `allow`-by-default pedantic on 1.98.1, so both readings were correct.

1.98.1 is what run 206 resolved and what `docker/ci/Dockerfile` already pins, so
`docker/ci/run cargo clippy …` on a desktop becomes a true stand-in for this
workflow instead of an approximation. The header says how to bump: the three
refs here and the Dockerfile's `FROM` in one commit, in a PR of its own, where
the lints the new version turns on are the diff.

Also: the corpus-report step's comment quoted `207/0/14`, a tally two baselines
old. It now describes the shape of the problem without pinning a number that
decays.

Closes #15.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fabi referenced this pull request

2026-09-18 05:18:02 +00:00

chore: hand the workspace over — the gated launchers, and the state of play #55

fabi merged commit e3d30fa652 into main

2026-09-19 18:48:01 +00:00

fabi referenced this issue from a commit

2026-09-19 18:48:02 +00:00

Merge pull request 'ci: pin the toolchain to 1.98.1 in all three jobs' (#54) from fix/ci-pin-toolchain into main

fabi referenced this issue from a commit

2026-09-19 20:29:49 +00:00

Merge pull request 'ci: pin the toolchain to 1.98.1 in all three jobs' (#54) from fix/ci-pin-toolchain into main

Sign in to join this conversation.