ci(release): refuse to publish a build from a modified checkout

[juacker]

The v26.8.1 Windows installer reports v26.8.1-dirty in Settings → About. This does not sanitise that string — it stops us shipping the artifact that earns it.

What the string means

src-tauri/build.rs bakes git describe --tags --always --dirty into CLAI_GIT_DESCRIBE; app_version_detail prefers it over CARGO_PKG_VERSION whenever it looks version-like. So the release job's checkout state is what users read in About.

The flag is truthful. git describe --dirty calls refresh_index() before run_diff_index() (git builtin/describe.c:802-815 @ v2.55.0, present since v2.20), so stat-only skew cannot produce it — bumping a file's mtime leaves describe clean (reproduced). Also ruled out on this repo: no CRLF-committed or mixed-eol tracked files (git ls-files --eol: 338 i/lf, 37 binary, 1 none), no tracked symlinks, no paths that fail to check out on Windows, and a clone with core.autocrlf=true stays clean. Something in the windows-latest job really modified tracked content. What, is still unknown.

My first attempt at this suppressed -dirty for tag-exact builds. Review killed it: it would have made releases stop reporting a real defect. Reverted — src-tauri/src/commands/app_info.rs is untouched.

What this does

1. scripts/assert-pristine-tree.sh — fails when tracked files differ from HEAD, printing git status + git diff --stat HEAD. It runs git update-index -q --refresh first, because git diff-index is plumbing that compares cached stat data with no content fallback: without the refresh, a fresh clone's mtimes alone fail a pristine tree (reproduced both ways).
2. Two call sites in release.yml — before the build (fail cheaply) and after it (the run that can honestly claim the uploaded assets match the tag; cargo rewriting the tracked src-tauri/Cargo.lock would land in that window). A post-build failure fails the build job that publish needs, so the release stays a draft and sync-to-r2 never runs.
3. .gitattributes: *.sh text eol=lf — the gate runs through bash on windows-latest, where Git for Windows would otherwise check the script out with CRLF and kill it on set -euo pipefail. Verified: in a core.autocrlf=true clone the .sh files stay LF while Makefile/*.ts do convert, and no file renormalises.
4. build.rs reports what it baked as a cargo:warning when CI is set — the value, or the reason nothing was baked.

Heads-up before merging

This gate would have failed v26.8.1's Windows job, so the next tag may fail until the cause is found. That is the intent — an artifact that cannot be mapped back to a commit should not reach users — but it is a policy call, hence draft. With git status in the log the investigation should be short.

The second half of the puzzle

The published Linux .deb and macOS .app for v26.8.1 contain the literal 26.8.1 exactly once and no v26.8.1 anywhere, i.e. no describe string was baked on those platforms at all, while Windows baked a dirty one. One tag, three platforms, three outcomes, and nothing in the build log said which. Not caused here, not fixed here; item 4 makes the next release say so out loud. (Cache staleness is excluded: swatinem/rust-cache@v2 does not cache workspace crates, and cargo replays build-script warnings.)

Verification

• cargo fmt; cargo clippy --lib; cargo test --lib app_info (unchanged code, still green); CI=1 cargo build --lib emits exactly one warning, without CI none.
• Script exercised on scratch repos: mtime-only skew → pass; real edit → fail; staged-only change → fail with a non-empty diff.
• Post-build false-positive check on a real build: npm run build then cargo build --release --lib (which runs tauri_build::build()), gate clean after each.
• Reviewed in four independent read-only rounds; reports in the workspace under reviews/version-stamp-*.md. Round 1 found the original approach wrong, rounds 3 and 4 returned production_quality.

CI has not run on this branch yet at the time of writing.

[juacker]

First data from the new instrumentation, this PR's own CI run (30829601896), both jobs green:

Check & Build (ubuntu)  warning: clai@26.8.1: CLAI_GIT_DESCRIBE=c740854
Windows check           warning: clai@26.8.1: CLAI_GIT_DESCRIBE=c740854

Two things follow.

1. The log line works, on both platforms, and ci.yml's shallow --no-tags checkout explains the bare hash — which resolve_version_detail already filters back to the crate version. So "no describe baked" is not a platform quirk; a job either has the tag or it does not. That makes the v26.8.1 Linux/macOS result (no describe string in the binary at all, not even a hash) stranger, not less strange: those jobs did fetch the tag. Still open.

2. windows-latest came out clean here — checkout + npm ci + cargo on Windows produced no -dirty. So whatever dirtied the v26.8.1 release tree is not generic Windows checkout behaviour; it is specific to the release job, i.e. the tag checkout or something inside tauri-action (vite, or the NSIS/WiX bundling that ci.yml never runs). That is exactly the window the second, post-build gate covers.