chore(ci): weekly renovation 2026-08-23 - #3880
Conversation
Rust stable reached 1.98.0 on 2026-08-20, so MSRV and the development toolchain move to 1.97 (latest stable - 1). The channel bump forces a flake.lock refresh: the locked rust-overlay (4a408e1f, 2026-06-02) carries stable manifests only up to 1.96.0, so nix flake check cannot resolve 1.97.0 without it. Only rust-overlay moves -- nixpkgs and crane do not need to know about the new channel. Also bumps cargo-llvm-cov 0.8.7 -> 0.9.0, the one cargo-install pin that had drifted. Every other pinned crate, the Nushell and PowerShell pins, and the Codex Cloud tools in dev/codex.sh are already current.
0.9.0 collapses consecutive misses into ranges, so the column the coverage investigation recipe sends you to no longer lists one line per miss. Say so where the recipe compares it against a codecov line list.
The statusline cache-check reads a trace that only exists because of -vv, and the diagnostic collector that writes the bundle runs its own git --version, git worktree list --porcelain, and gh --version after the render. Those land in the same trace, so the .cache report flags two same-context duplicates on an otherwise clean render -- which costs a fresh investigation every week. Name them, and say where in trace.log to confirm.
There was a problem hiding this comment.
Reviewed the whole sweep against upstream: stable is 1.98.0 (2026-08-20), so 1.97 is the right MSRV; cargo-llvm-cov 0.9.0 is the only drifted pin and it is the only cargo-llvm-cov pin site in the repo; every other pinned crate matches its newest crates.io release and every rust-version clears 1.97.0. The rust-overlay entry checks out on everything reachable without Nix — f60c1b57 exists, lastModified 1787454509 is its committer date to the second, manifests/stable/1.97.0.nix is present there and 404s at the currently-locked revision. The nix-flake job does fire on this PR (the gate paths filter matches Cargo.toml, rust-toolchain.toml, and flake.lock), so the narHash gets the real check.
Three findings — I've pushed fixes for all three rather than leaving inline suggestions, since this is a bot-authored PR with no human author to apply them.
Two nightly jobs are red because of this PR, and it isn't a flake
nightly.yaml pins its own toolchain twice — minimal-versions and check-unused-dependencies both do rustup override set nightly-2026-03-01, which resolves to 1.96.0-nightly. With rust-version now 1.97, cargo refuses before either check runs:
error: rustc 1.96.0-nightly is not supported by the following packages:
worktrunk@0.74.0 requires rustc 1.97
wt-perf@0.1.0 requires rustc 1.97
Both jobs failed with that identical error. This is deterministic and PR-caused: the last two nightly runs on main failed only on link-check, with both of these green. It would also follow the PR onto main — nightly's push trigger lists **/Cargo.toml, so the post-merge run fails the same way.
The pin is stale rather than newly wrong. It was set on 2026-05-07 in #2636 and never moved; the previous MSRV of 1.96 was the last one it could satisfy, so this bump is where it runs out. The reason nothing caught it is that the weekly MSRV task's file table lists only Cargo.toml, tests/helpers/wt-perf/Cargo.toml, and rust-toolchain.toml — a fourth place in the repo pins a toolchain and isn't on the list.
Pushed as 7d1b466: both pins move to nightly-2026-08-01 (1.99.0-nightly), which clears the MSRV with two release cycles of headroom instead of landing exactly on it, plus a comment stating the constraint on each and a row in the skill's MSRV table so the weekly pass owns them from here.
command_count counts the collector's calls, against a baseline that predates them
The new bullet is right that the -vv collector's git worktree list --porcelain, gh --version, and git --version land in the same trace — but the sentence added just below it points at command_count as "the number to read" against the ~29 baseline, and command_count is every subprocess record in the trace, so it includes those same three calls.
The baseline is collector-free. It was measured in #2211 with RUST_LOG=debug … | grep wt-trace | wt-perf cache-check — no -vv, no bundle. #3825 switched the recipe to -vv plus config state logs profile without re-measuring it. So command_count runs about three high against 29, which is the entire width of the ~32 investigate threshold. Nothing was misread this week (27 is under it either way), but a render that genuinely drifted to 30 would read as 33 and draw an investigation, and one at 32 reads as clean at 29.
Pushed: the sentence now says command_count includes the collector's three calls and that the baseline predates them, so a comparison subtracts them first.
.git/wt/logs/trace.log is the path shape this skill warns about
The confirmation step sends you to .git/wt/logs/trace.log, and the recipe above it says "Run from any worktree of this repo." In a linked worktree .git is a gitdir file, so that read fails with ENOTDIR — which is exactly what the Issue Triage section of this same file already tells us not to hand people, with $(git rev-parse --git-common-dir)/wt/logs/ as the form that resolves from anywhere. Pushed the same substitution here.
Not blocking
cargo-llvm-cov 0.9.0 also stops emitting build scripts under Cargo's new build-dir layout. coverage.yaml uses --cobertura, not --show-missing-lines, and build.rs sits outside the src/-only report, so I don't expect movement — but this PR's own code-coverage run is the first one on the new version, so it's the place to notice if the project number shifts.
On the macos-15 note: agreed it's a separate PR, and worth taking before the deprecation lands rather than after, given how much of the snapshot surface is macOS-specific.
After the fix — where CI landed
The nightly run on bc35d51 (which carries 7d1b466) has minimal-versions and check-unused-dependencies both green, so the pin bump is confirmed rather than assumed. nix-flake also passed there — that is the real check on the hand-computed narHash, so the one part of this PR that couldn't be verified without Nix now has been. Required checks, msrv, codecov/patch and codecov/project are all green.
Two reds remain, and neither is this PR's: check-docs and link-check both die in npm ci with the @astrojs/check peer conflict against typescript@7.0.2, before either reaches its actual work. That is already red on this PR's merge base (be2c088a) and is what #3877 fixes. Worth knowing that my push is why they are visible here at all — .github/workflows/nightly.yaml is in ci.yaml's docs paths filter, so touching it flipped check-docs from skipped to running. Merging #3877 first should clear both.
The MSRV bump to 1.97 in this PR fails both nightly jobs that pin their own toolchain: `rustup override set nightly-2026-03-01` resolves to 1.96.0-nightly, and cargo refuses a workspace whose `rust-version` exceeds the toolchain, so `minimal-versions` and `check-unused-dependencies` both die with "rustc 1.96.0-nightly is not supported" before running their checks. It would follow the merge onto main too -- nightly's push trigger lists `**/Cargo.toml`. The pin was set in #2636 and never moved; 1.96 was the last MSRV it could satisfy. Move both to nightly-2026-08-01 (1.99.0-nightly), which clears the new MSRV with two release cycles of headroom instead of landing on it, and say so on the line so the constraint isn't rediscovered. Add the pins to the weekly MSRV file table, which listed only the three manifests -- the reason nothing caught this before the bump landed. Also fixes two things in the statusline cache-check the previous commit touched: `command_count` includes the -vv collector's three calls, against a baseline measured in #2211 before the recipe used -vv (#3825 switched it without re-measuring), so it reads ~3 high against a threshold only 3 wide; and `.git/wt/logs/trace.log` is the gitdir-file path shape this same skill warns about, since the recipe says to run from any worktree.
The MSRV section assumes the Determinate installer works, but it escalates via sudo and the weekly runner has none, so this week's bump hit a dead end with the lock refresh non-optional: nix flake check can't resolve a channel the locked rust-overlay predates. Write down the fallback that worked -- compute the narHash from the NAR serialisation, and validate the script against the entry already in the lock before trusting it on a new revision.
|
All three review findings were pushed before the review was submitted, so there's nothing outstanding to apply — but none of them had actually been verified by CI at that point, and one of the checks that matters most had never run. It has now. The nightly-pin fix is confirmed.
Also clears the not-blocking note from the review: Full check state on
|
| head | nix-flake |
minimal-versions |
check-unused-dependencies |
|---|---|---|---|
f9292b41 (pre-fix) |
cancelled | failure | failure |
7d1b466c (fix) |
cancelled | cancelled | cancelled |
bc35d518 (current) |
success | success | success |
1 participant
Summary
Weekly CI renovation. Rust stable moved to 1.98.0 on 2026-08-20, so MSRV and the development toolchain go to 1.97 (latest stable − 1); one cargo-install pin had drifted. Everything else is already current.
Cargo.toml,tests/helpers/wt-perf/Cargo.toml,rust-toolchain.toml(1.97.0), plus theflake.lockrefresh the channel bump requires.cargo-llvm-cov: 0.8.7 → 0.9.0 —coverage.yaml. MSRV 1.87, well under the pinned toolchain.Toolchain compatibility for every other pinned crate against 1.97.0:
cargo-affected0.4.0 (1.94),cargo-insta1.48.0 (1.66.0),cargo-nextest0.9.143 (1.91),cargo-llvm-cov0.9.0 (1.87),cargo-msrv0.19.3 (1.91.1),lychee0.24.2 (1.88.0),worktrunk0.74.0 (1.96),cargo-udeps0.1.61 (unspecified). All build under 1.97.0.nightly-2026-03-01→nightly-2026-08-01—nightly.yaml×2. Not drift: the MSRV bump broke these two jobs, see below.The remaining commits are fallout from the same sweep:
cargo-llvm-cov0.9.0 changes the shape of the--show-missing-linescolumntests/CLAUDE.mdsends you to during a codecov investigation, and the weekly statusline cache-check has been reporting two duplicates that are artifacts of its own-vvflag.The MSRV bump broke two nightly jobs; that is fixed here
check-unused-dependenciesandminimal-versionseach pin their own toolchain, andnightly-2026-03-01is1.96.0-nightly— so raisingrust-versionto 1.97 made cargo refuse the workspace outright, before either job ran its actual check:Both are now on
nightly-2026-08-01(1.99.0-nightly), which clears the new MSRV with headroom rather than landing on it. Reproduced locally in both directions:cargo +nightly-2026-03-01 checkfails with the error above,cargo +nightly-2026-08-01 checkpasses. The coupling is easy to miss because neither failure mentions udeps or minimal versions, so the constraint is now stated on both lines and in the weekly MSRV file table.The
flake.lockbump was computed by hand — please letnix-flakeconfirm itrust-toolchain.tomlmoving to1.97.0forces a lock refresh: the lockedrust-overlay(4a408e1f, 2026-06-02) carries stable manifests only up to1.96.0, sonix flake checkcannot resolve the new channel.rust-overlayis bumped tof60c1b57(2026-08-23), which has1.97.0.nix.nixpkgsandcraneare left alone — onlyrust-overlayhas to know about the new channel, and a fullnix flake updateis a wider change than this PR needs.This session could not run
nix flake update: the weekly runner has no Nix and no passwordlesssudo, so neither the Determinate installer (which escalates viasudo) nornix-portable(which fails its build self-test) works here. The lock entry was therefore computed directly from the NAR serialisation, and the method was validated first by recomputing the existingrust-overlayentry from its own revision and gettingsha256-7mDa7OBAaf7MU6ZovT9ENfD62kH911SsSazBb4KTDF0=back byte-for-byte — the value already inflake.lock. The same script then produced the new entry.That is a strong check but not the real one.
nightly'snix-flakejob runsnix flake checkand fires on this PR (the paths filter matchesrust-toolchain.toml,Cargo.toml, andflake.lock), so it is the gate that actually proves the lock evaluates. It has now run on this head and passed, so the computed lock resolves the 1.97.0 channel and the flake's checks build under it. Flagging the provenance anyway, since a hand-written lock entry deserves a second look on review.How the hash was computed
Nix serialises the unpacked flake input as a NAR and reports SHA-256 of that stream in SRI form. The format is length-prefixed strings padded to 8 bytes, with directory entries in bytewise-sorted order; a ~90-line Python script reproduces it from the GitHub tarball with the top-level
<repo>-<rev>directory stripped, which is the same tree Nix hashes.Already up to date
cargo-affected0.4.0,cargo-insta1.48.0,cargo-nextest0.9.143,cargo-msrv0.19.3,cargo-udeps0.1.61,lychee0.24.2,worktrunk0.74.0 (matches the newest crates.io release)dev/codex.shdev/codex.sh: pre-commit 4.6.2, cargo-insta 1.48.0, cargo-nextest 0.9.143, PowerShell 7.6.5;setup-web's own Nushell and PowerShell pins agreeubuntu-24.04andwindows-2022(the latter deliberately pinned — Windows-latest workflows will use Windows Server 2025 image in GH actions/runner-images#12677)Found, not bumped:
macos-15is no longer whatmacos-latestresolves toci.yaml's header comment saysubuntu-24.04, macos-15are "pinned to current -latest equivalents". That is still true of Ubuntu but no longer of macOS:macos-latestnow resolves to macOS 26 arm64, andmacos-15has become the older of the two GA images — which, under the runner-images deprecation policy ("deprecation of the oldest image label begins once the newest OS image label has been released to GA"), is the one that starts aging out next.macos-14already carries the deprecated badge.Not bumped here, because it is an OS upgrade rather than a version pin, and this repo drives PTY and shell-integration snapshots on macOS that a new image and Xcode can move. There is also nothing this session can do to check it — the only macOS available to it is the
test (macos)job on a PR, and a red macOS matrix would have blocked the MSRV bump alongside it. Flagging rather than guessing at the timing: whether to take macOS 26 now or wait for the deprecation announcement is a call about this repo's snapshot surface. Happy to open it as its own PR if you want the signal.CI
Green, including
nix-flake,msrv,minimal-versions,check-unused-dependencies, all threetestlegs, andcodecov/patch.Two jobs are red and neither is from this PR:
check-docsandlink-checkboth fail in their sharednpm cistep withERESOLVEagainsttypescript@7.0.2. Both fail the same way onmain's head (be2c088a), and #3877 is the open fix.Weekly checks that produced no change
gpt-5.6-lunais still how OpenAI's models page positions the "fast and affordable … lowest cost in the family" 5.6 variant;gpt-5.3-codex-sparkis a Pro-only research preview, not a default.haiku/claude-haiku-4.5is still the smallest current Anthropic model.command_countwas 27, which includes the three calls the-vvdiagnostic collector makes after the render, so the render itself is ~24 against a ~29 baseline measured before the recipe used-vv. The two duplicates the report flagged (gh --version,git worktree list --porcelain) are that same collector, not the render. Both the baseline arithmetic and the trap are now written down in the skill.metadata.pluginRootresolution, but.claude-plugin/marketplace.jsonnames an explicit./plugins/worktrunksource rather than a bare name, so it is unaffected; theWorktreeCreate/WorktreeRemovehooks and the statusline stdin schema are unchanged (workspace.git_worktreeandworkspace.repoexist but predate this window by several hundred releases). Codex, Gemini CLI, and OpenCode shipped only routine releases.Verification
rustupresolves the new channel:cargo 1.97.0 (c980f4866 2026-06-30),rustc 1.97.0 (2d8144b78 2026-07-07),clippy 0.1.97.cargo clippy --all-targets --all-features -- -D warningspasses on 1.97.0 — the check that matters most for a toolchain bump, since it compiles every target and feature under the new rustc and holds the new clippy to zero warnings. Doctests passed too.test_copy_ignored_preserves_file_executable_permissions, which expects0644and got0664. That is this sandbox'sumask 0002, not the toolchain; thetest (linux|macos|windows)matrix is the real gate.cargo run -- hook pre-merge --yesis not a clean local signal on this runner: it ends onpre-commit: exit status: 127because pre-commit isn't installed in the tend sandbox, unrelated to the bump.cargo msrv verifywas not run locally (it rebuilds the graph per candidate);ci.yaml'smsrvjob covers it.cargo info/ crates.io for the cargo tools,static.rust-lang.org/dist/channel-rust-stable.tomlfor Rust stable (1.98.0, 2026-08-20), thenushell/nushellandPowerShell/PowerShellrelease APIs, PyPI for pre-commit,actions/runner-imagesREADME for the image labels, and the vendors' own model pages for the LLM pins.rust-overlayat the currently-locked revision was confirmed to stop at1.96.0.nix, and at the new revision to contain1.97.0.nix— this is why the lock has to move at all.