build(ci): pin the Rust toolchain and guard against pin drift - #10
Merged
Conversation
`cargo fmt --all -- --check` and `cargo clippy -D warnings` both failed on
main under rustc 1.97.1. No source change caused this: `useless_concat` and
`unneeded_struct_pattern` are recent clippy lints, and CI pins nothing.
Three clippy fixes, all in test code and all semantics-preserving:
- codex.rs: two single-argument `concat!(..)` calls collapsed to plain
string literals (clippy::useless_concat).
- ingest_file.rs: `IngestOutcome::Skipped { .. }` -> `IngestOutcome::Skipped`;
it is a unit variant (clippy::unneeded_struct_pattern).
Then `cargo fmt --all`, which rewrapped 18 over-width assertion lines across
the two adapters, adapters/common.rs, and four integration tests. Mechanical
line-wrapping at the 100-column limit only.
No production code touched. Verified green: fmt, clippy (lore-core/lore-ipc
and lore-app), cargo test --locked --all-targets (346 pass / 4 ignored),
no_network_in_archive, no_egress, egress-check.sh, IPC bindings in sync,
npm lint/typecheck/test (148 pass).
Follow-up: pinning the toolchain so this cannot recur.
CI ran `dtolnay/rust-toolchain@stable` with `cargo clippy -- -D warnings`, so
any new lint in a stable release broke the build on a commit that changed
nothing. That is not hypothetical: it is exactly how main went red under
1.97.1 (previous commit). Pinning turns a toolchain upgrade into an explicit,
reviewable change.
- rust-toolchain.toml pins 1.97.1 with rustfmt/clippy and the minimal
profile. rustup honors it for every cargo invocation, locally and in CI.
- Both workflows now reference dtolnay/rust-toolchain@1.97.1 rather than
@stable, so the runner pre-installs the same compiler rustup would fetch
(the action does not read rust-toolchain.toml — verified against its
README; @1.97.1 is a valid ref).
- scripts/toolchain-pin-check.sh fails if the toml channel, the workflow
action refs, and the active rustc are not all the same version. Wired in
as the first step of the rust-core job, ahead of fmt/clippy. Verified it
passes when aligned and fails when the toml and workflows disagree.
This is not the MSRV. `rust-version = "1.90"` in Cargo.toml still declares the
minimum supported compiler; this pins the one we build and lint with.
Verified: pin check, fmt, clippy (both invocations), cargo test --locked
--all-targets (346 pass / 4 ignored), both workflow files parse as YAML.
hsusul
force-pushed
the
build/pin-rust-toolchain
branch
from
August 22, 2026 21:56
29ce4a6 to
26e9b06
Compare
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.
Problem
CI runs
dtolnay/rust-toolchain@stableand thencargo clippy -- -D warnings. Every new lint in a stable rustc release becomes a build failure on a commit that changed nothing. #9 exists because of exactly that.Changes
rust-toolchain.toml— pins1.97.1withrustfmt/clippyand the minimal profile. rustup honors this for every cargo invocation, locally and in CI, so it is the real source of truth.Both workflows now use
dtolnay/rust-toolchain@1.97.1instead of@stable. The action does not readrust-toolchain.toml— I checked its README — so without this the runner would pre-install one compiler while rustup built with another.@1.97.1is a valid ref (confirmed against the action's branch list).scripts/toolchain-pin-check.sh— the two pins above can't reference each other, so this asserts they agree, and that the activerustcmatches too. It runs as the first step of therust-corejob, ahead of fmt and clippy.I negative-tested the guard: it passes when aligned, and fails with
workflow uses dtolnay/rust-toolchain@1.97.1 but rust-toolchain.toml pins 1.96.0when I desynced them.README gains a short note on why the pin exists.
Not the MSRV
rust-version = "1.90"inCargo.tomlstill declares the minimum supported compiler. This pins the one we build and lint with. Those are different things and the toml comment says so.Separately worth noting: the MSRV is currently never verified in CI — nothing builds against 1.90. Out of scope here, but it means that number is unproven.
Upgrading later
Bump
channelinrust-toolchain.tomland the@<version>refs in both workflows. The guard fails the build if you only do one. Dependabot'sgithub-actionsecosystem (coming in a later PR in this series) will see the pinned action ref and open bump PRs for it.Verification
./scripts/toolchain-pin-check.shcargo fmt --all -- --checkcargo clippy -p lore-core -p lore-ipc --all-targets --all-features -- -D warningscargo test --locked -p lore-core -p lore-ipc --all-targets