4 Commits

Author	SHA1	Message	Date
Worktrunk Bot	1b278042de	chore(ci): weekly renovation 2026-08-16 (#3826) ... ## Summary Weekly CI renovation check found the following updates: - `worktrunk`: 0.72.0 → 0.74.0 (MSRV 1.96, compatible with our 1.96.0) — `ci.yaml` ×2, `nightly.yaml` - `nushell`: 0.114.1 → 0.115.0 — `nightly.yaml`, `benchmarks.yaml`, `coverage.yaml`, `actions/test-setup`, and `scripts/codex-cloud/Taskfile.yaml` - `pre-commit`: 4.6.1 → 4.6.2 — `scripts/codex-cloud/Taskfile.yaml` - `PowerShell`: 7.6.4 → 7.6.5 — `scripts/codex-cloud/Taskfile.yaml` and the root `Taskfile.yaml`'s `setup-web` task The Codex Cloud archive checksums were recomputed from the new upstream tarballs, and the resulting `Taskfile.yaml` digest (`f14dbc89…`) is copied into both README launcher commands. The `setup-web` PowerShell pin came in as a follow-up commit: the initial sweep only grepped `.rs`/`.md`/`.toml` for stale versions, so the root `Taskfile.yaml`'s `PWSH_VERSION="7.6.4"` was missed. Nothing tests the two PowerShell pins against each other, so that one drifts silently — worth a note for future renovation runs. The `powershell_7.6.5-1.deb_amd64.deb` asset the `setup-web` branch downloads is present in the v7.6.5 release. ## Already up to date - Rust stable is 1.97.1, so MSRV and toolchain stay at 1.96 (latest stable − 1) — `Cargo.toml`, `tests/helpers/wt-perf/Cargo.toml`, `rust-toolchain.toml` need no change, and `flake.lock` is untouched. - `cargo-insta` 1.48.0, `cargo-nextest` 0.9.143, `cargo-llvm-cov` 0.8.7, `cargo-msrv` 0.19.3, `cargo-affected` 0.4.0, `cargo-udeps` 0.1.61, `lychee` 0.24.2 - Task 3.52.0 (mise, Codex Cloud) - Runner images: ubuntu-24.04, macos-15, windows-2022 ## Held back: zola 0.22.1 → 0.23.3 Not bumped. Zola 0.23.0 shipped [Tera2 + refactoring](https://github.com/getzola/zola/pull/3105), which is a templating-engine swap rather than a routine release. Building `docs/` with the 0.23.3 binary fails at the first line of `templates/base.html`: ``` ERROR error: Unknown tag --> base.html:1:4 | 1 | {% import "macros.html" as macros %} | ^^^^^^ ``` `templates/base.html` and `templates/macros.html` are the two files that use the `import`/`macro` pair, so the migration looks small, but it is template work with its own review rather than a pin bump — kept out of this PR so the rest can land. Raised separately. <details><summary>Verification</summary> - Every version above was read from the upstream source of truth: `crates.io` for the cargo tools, `nushell/nushell` and `PowerShell/PowerShell` releases, PyPI for pre-commit, and `static.rust-lang.org/dist/channel-rust-stable.toml` for Rust stable (1.97.1). - Checksums were computed from the downloaded archives and the extracted binaries were run (`nu --version` → `0.115.0`); the archive layouts (`nu-<ver>-x86_64-unknown-linux-gnu/nu`, top-level `pwsh`) are unchanged, so the `install_binary` paths still resolve. - All six edited YAML files parse. - The nushell bump was exercised against the shell-integration suite: `cargo test --features shell-integration-tests --test integration -- nushell` with 0.115.0 on `PATH`. 13 of 14 pass; `test_nushell_install_target_is_a_vendor_autoload_dir` fails — but it fails identically on the currently-pinned 0.114.1, and passes on *both* versions when run alone. It is a pre-existing shared-state race in the sandbox, not a regression from this bump: the test asserts against the real user `$nu.vendor-autoload-dirs` entry rather than one under its temp `HOME` (nu resolves the home dir from the passwd database, so the test's `HOME` override does not move it), and a sibling uninstall test in the same filter removes `wt.nu` from that shared directory. Noted rather than fixed here — it is unrelated to the pins. - The zola failure above was reproduced with the official 0.23.3 `x86_64-unknown-linux-gnu` release binary against this repo's `docs/`. </details> --------- Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>	2026-08-17 01:48:26 -07:00
Worktrunk Bot	ec574b6c35	ci: bump pinned cargo-nextest 0.9.143 and worktrunk 0.72.0 (#3783) ... ## Summary Weekly CI pin check found the following drift (these inline `version:` strings are invisible to Dependabot — it follows `Cargo.toml` deps and `uses: foo@vN` refs, not pinned versions inside `with:` blocks): - `cargo-nextest`: 0.9.140 → 0.9.143 (MSRV 1.91, compatible with our 1.96) — pinned in `coverage.yaml`, `actions/test-setup`, and `actions/claude-setup`; all three moved together. - `worktrunk`: 0.71.0 → 0.72.0 (MSRV 1.96, compatible with our 1.96) — the CI-installed `wt` that runs `wt hook pre-merge`, bumped to the current release; pinned in `ci.yaml` (×2) and `nightly.yaml`. ## Already up to date - `cargo-affected`: 0.4.0, `cargo-insta`: 1.48.0, `cargo-llvm-cov`: 0.8.7, `cargo-msrv`: 0.19.3, `cargo-udeps`: 0.1.61, `lychee`: 0.24.2 - `hustcer/setup-nu` (nushell): 0.114.1 — matches the current nushell release across all four call sites - Runner images: ubuntu-24.04, windows-2022 ## Notes - windows-2022 stays pinned ([actions/runner-images#12677](https://github.com/actions/runner-images/issues/12677) — windows-2025 lacks the D: drive). - **cargo-nextest 0.9.143 has nothing config-facing to adjust.** The 0.9.140 → 0.9.143 range is dynamic-library-search-path fixes (build-dir layout v2, `build.build-dir`, `[[example]]` targets), archive filterset fixes, an opt-in `junit.report-skipped` setting we don't set, and a listing progress bar. The one behavior change — ordering the Cargo artifact directory ahead of `deps` on the dylib search path, matching Cargo since 1.93 — doesn't affect this repo, which links no `dylib` dependency. - **worktrunk 0.72.0 is only exercised through `wt hook pre-merge`** in these three jobs, so the release's `wt merge` / `wt step push` two-tree changes and the `branch_outcome` JSON rename don't reach CI. The relevant one is the opposite direction: 0.72.0 fixes `wt` writing ANSI to a pipe and exiting 101 on `Broken pipe`, which is exactly the non-tty shape these jobs run in. - **`zola` is deliberately left at 0.22.1** — see below. ## Deferred: zola 0.22.1 → 0.23.2 `taiki-e/install-action`'s `tool: zola@0.22.1` in `check-docs` (and the matching pin in `publish-docs.yaml`) is behind, but 0.23.0 is not a routine bump. Upstream calls it "probably the most breaking version of Zola that will happen" ([CHANGELOG](https://github.com/getzola/zola/blob/master/CHANGELOG.md)): **shortcodes are removed entirely** and Tera is updated to v2 with its own [migration guide](https://github.com/Keats/tera/blob/master/MIGRATION.md). `docs/templates/shortcodes/` and `docs/templates/macros.html` both exist, so this needs a real docs-site migration rather than a version-string change, and it would land in the same PR as the live-site publish pin. Left for a separate change; flagging it here so it isn't silently skipped each week. Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>	2026-08-09 04:56:50 -07:00
Maximilian Roos	1b35950a9c	test: simplify the integration suite (#3657) ... This reduces duplicated and false-confidence integration coverage while preserving the suite's semantic and user-facing contracts. ## What changed - Replaces three overlapping list-layout suites with two representative CLI integrations, leaving exhaustive geometry at the direct layout layer. - Groups Git error render variants into labeled family snapshots and removes command-by-shell wrapper cross-products while retaining shell-specific conformance and regression cases. - Updates test-authoring guidance around boundary choice, minimal contrasts, and PTY use, and runs local and CI coverage through Nextest isolation. ## Results - Test catalog: 4,642 to 4,562 - Snapshots: 1,193 to 1,131 - Warm all-feature runtime: 84.70s to 78.17-80.35s - Full coverage: 97.32% of lines ## Testing - `cargo run -- hook pre-merge --yes` - `cargo llvm-cov nextest --features shell-integration-tests --summary-only` > _This was written by Claude Code on behalf of max_.	2026-07-29 18:54:19 -07:00
Maximilian Roos	4202cffe61	fix(ci): split ci by cadence so coverage uploads on every main commit (#3608) ... ## What prompted this Getting #3605 green ran into codecov reporting a `base_commit` three commits older than the real merge-base. This audits whether our config causes that. ## The cause Codecov picks a PR's base by walking back to the newest ancestor that has a coverage report. It used the real merge-base for PRs #3480, #3532 and #3602, and a stale one for #3603 and #3605. The difference is whether the merge-base uploaded a report. **29 of the last 40 main commits did not.** `ci` had one concurrency group for main pushes, and GitHub cancels the *pending* run in a group whenever a newer one joins, even with `cancel-in-progress: false`. So the question is how long a run holds the group, and a run isn't done until its slowest job is: | job | duration on main | |-----|------------------| | `fast-checks` | 2 min | | `code-coverage` | 3-4 min | | `test (windows)` | 11 min | | `collect affected coverage (windows)` | 110-129 min | Each main run held the group for ~2 hours, so nearly every subsequent main push was cancelled while queued, taking the 4-minute coverage job with it. Every cancelled main run's `updated_at` lands within a second of the next push's `created_at`. The 2 hours is real work, not queue: 2-5s from `created_at` to `started_at`, then 108 minutes inside `cargo affected collect` — 4181 tests under `-C instrument-coverage` with a per-test LLVM profile, ~5 GB of profraw. ## The fix: one workflow per cadence The three groups of jobs have incompatible needs, and one group was serving all of them. | workflow | cadence on main | why | |----------|-----------------|-----| | `ci` | every commit, ~11 min | required gate + fast checks | | `coverage` | every commit, keyed per-sha | a skipped upload leaves later PRs on a stale base | | `affected` | sampled, ~2 h | a DB a few commits old still anchors a correct superset | `affected` keeps exactly the grouping it has today, so its sampling is unchanged and deliberate. It just no longer drags the other two along. ### Scope of the impact The posted `codecov/patch` check scopes to the PR's own GitHub diff, so a stale base did **not** score PRs against other people's lines. On #3605 the posted 91.66% is exactly `github.rs`'s 11/12, while the stale-base compare object reported 64/65 across 13 files. What a stale base costs: - `codecov/project` reports "compared to \<stale sha\>" - the patch `auto` target is the stale base's project coverage (0.02pp here) - the compare API object widens to `base..head`, which is what made the investigation look like silence Separately, `test`/`lint`/`fast-checks` also stopped completing on main. Nothing load-bearing rode on that (they already ran on the PR), but it left `tend-ci-fix` with nothing to watch, since it doesn't fire on cancelled runs. ## Two smaller fixes - `ignore: "**/tests/**"` compiles to `.*/tests/.*` (confirmed against codecov's validator), which needs a leading directory and so never matched `tests/` itself. Inert today since `cargo llvm-cov` reports only `src/` (verified against a downloaded `cobertura.xml`), but now correct if that changes. Now `tests/**`. - `fail_ci_if_error` gated on `github.repository_owner`, which is the *base* repo's owner on a fork PR too, so the soft-fail its comment describes never applied. It keys off the head repo now. ## Docs The API behaviour was ours to misuse, not codecov's to explain. Three traps, all confirmed against the live API: - `file_report/<path>/` 404s with `coverage info not found` because the route swallows the trailing slash into the path. Without it the endpoint returns `line_coverage`. - `?pullid=N` always compares the PR's **current** head. `?base=&head=` asks about an earlier commit. - the compare response has no `patch_totals` key, and `.name` is `{base, head}` rather than a string, so a filename lookup silently matches nothing. A working recipe already existed in `running-tend`, but that skill is scoped to CI. `tests/CLAUDE.md` owns coverage investigation, so the queries go there and `running-tend` points at them instead of keeping a second copy. Re-running the corrected query against #3605's failing commit reproduces the miss exactly: `src/git/remote_ref/github.rs:164`, the `gh repo set-default` hint, matching what the session eventually found by hand. ## This PR demonstrates it It changes no Rust at all, only YAML and markdown. Codecov still reported a **10-file, 111-line patch** on its first commit, because it based the comparison on `203603909` rather than the real merge-base `32f380a27`. Every main commit in between has no report: | commit | ci run | report | |--------|--------|--------| | `32f380a27` | queued | no | | `9645e3e13` | cancelled | no | | `bcd1ffdfd` | cancelled | no | | `8865f20ab` | cancelled | no | Every one of those 111 patch lines belongs to somebody else's merged commit. It passed at 100% only because those commits are well covered. > _This was written by Claude Code on behalf of @max-sixty_ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>	2026-07-26 20:19:15 -07:00