Files
max-sixty__worktrunk/Taskfile.yaml
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

17 KiB