mirror of
https://github.com/max-sixty/worktrunk.git
synced 2026-09-14 20:00:38 +08:00
Maximilian Roos
062cf57d8e
Both `Install cargo-affected` steps in `affected.yaml` installed from git with no rev, so the tool version on any run was whatever had last merged to cargo-affected's default branch. That cut both ways today: an upstream regression made `cargo affected run` abort with `git diff stdout was not valid UTF-8: invalid utf-8 sequence of 1 bytes from index 136455` on all three OSes, turning the advisory legs red repo-wide, and the fix (cargo-affected #69) then arrived the same way. Neither change is visible in this repo's history. cargo-affected publishes to crates.io as of 0.3.1, so it can carry a `version: "=X.Y.Z"` pin like every other `baptiste0928/cargo-install` block here. `=0.3.2` is what the unpinned installs already resolve to, so nothing changes behaviorally today. Two things it buys: - The crate joins the weekly tend pin sweep, which reads `version:` strings and now covers `affected.yaml`. The `cargo-install` action's own drift annotation starts firing for it too. - The existing "bump the `db-v{N}` cache marker if cargo-affected ships an on-disk schema change" rule becomes enforceable. It was unfollowable against a floating version, since the schema could change with no diff to notice. The pin appears twice, once per job, which is a new way to be wrong. A drift between the two hits `migrate_legacy_tables`, which drops and rebuilds the coverage tables rather than erroring, so selection silently degrades while the advisory job stays green. That is recorded in the workflow's cache-contract comment and in the tend skill's bump list. `cargo-affected`'s `rust-version` is 1.94, against this repo's pinned 1.96.0 toolchain. ## Testing The `affected tests (…, advisory)` legs on this PR exercise the change directly: they resolve `=0.3.2` from crates.io rather than from git. > _This was written by Claude Code on behalf of max_ Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>