fix(ci): toolchain-sync gates a bump on a Windows cross-compile, not host-only#501
Merged
Merged
Conversation
…host-only The fresh-bump probe in `just toolchain-sync` validated only the maintainer's host (aarch64): its Phase-2 clippy explicitly punted Windows to the Nightly Canary. So a nightly that compiles + lints clean on the host but breaks the SHIPPED Windows binary — a cfg(windows)-only regression the host never compiles, or an x86-only one — could be green-lit, only to fail later at the pre-push `cargo xwin` step or CI's Windows job. Add Phase 2b: after the host clippy passes, add the x86_64-pc-windows-msvc target to the candidate and run `cargo +CANDIDATE xwin clippy --target x86_64-pc-windows-msvc --all-features -D warnings`. On any failure the candidate steps back exactly like the host gate, so a bump is never accepted on a nightly that cannot build Windows. cargo-xwin is required up front (refuse rather than silently fall back to a host-only, unsafe bump). Validated: the gate accepts nightly-2026-06-26 (exit 0) and rejects nightly-2026-06-30 (33 chunks_exact lints under -D warnings). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.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.
Problem
just toolchain-sync(theship --freshstep-00 bump probe) validated a candidate nightly host-only (aarch64). Its Phase-2 clippy comment said it outright: "Windows-only lints stay the Nightly Canary's job; this probe runs on the maintainer's host."So a nightly that compiles + lints clean on the host but breaks the shipped Windows binary — a
cfg(windows)-only regression the host never compiles (e.g. the newcoverage.rs/sweep.rs/broker code), or an x86-only one — could be green-lit, only to fail later at the pre-pushcargo xwinstep or CI's Windows job. That's what bit the v0.6.18 ship.Fix
Add Phase 2b: a Windows cross-compile gate. After the host clippy passes, add the
x86_64-pc-windows-msvctarget to the candidate and run:On any failure the candidate steps back one day, exactly like the host gate — so a bump is never accepted on a nightly that can't build Windows.
cargo-xwinis now required up front (refuse rather than silently fall back to a host-only, unsafe bump).Validation
Run locally against the real nightlies:
nightly-2026-06-26(exit 0)nightly-2026-06-30(33chunks_exactlints under-D warnings)Note: CI does not run
toolchain-sync(it's maintainer-only —toolchain-ensureis the CI path), so this local proof is the validation.🤖 Generated with Claude Code