[kylekz]

Faster CI and releases for dv, measured on warm caches against a baseline run of the same commit.

What changes

• script/check --e2e-only (step 5 alone). On Windows and Linux, CI runs script/check as two jobs at once: --fast (with --linux on Linux) and --e2e-only. Together they cover every step, so the gates stay the same.
• Docs-only changes skip CI: docs/, the root Markdown and tests/e2e/README.md. No gate reads them. crates/dv_cli/skill/SKILL.md is code and still runs CI.
• The release reuses main's CI run. A tag's commit is on main, and the push of that commit ran ci.yml moments before the tag. When that run passes, the release waits for it instead of running every gate again with no cache. With no such run, or one that didn't pass, the release runs ci.yml itself, as today.
• The release's static musl dv is its own job, so the Windows release starts after ~1.5 min instead of waiting ~14.6 min for the AppImage.

Measured (one run each, warm cache; runner noise is ±15–40% per step)

	Before	After
CI run, wall-clock	14.0 min	8.3 and 9.1 min (two runs)
Windows	14.0 min	6.0 (--fast) + 8.2 (--e2e-only) at once
Linux	9.4 min	6.0 (--fast --linux) + 6.7 (--e2e-only) at once
macOS	5.8 min	unchanged
Release (critical path)	~34 min (CI run cold)	~15–18 min (estimated)

Not tested by a release

Releases are the owner's, so release.yml hasn't run. Its new jobs were run by a stand-in workflow on a scratch branch: main-ci finding main's passing run, main-ci waiting on a run in progress, the CI job skipped, the musl build alone with its artifact downloaded and run, and the publish condition. The fallback (no run on main, so ci.yml runs here) and the release environment step haven't run.

Tried and rejected

• e2e --jobs 4. Linux 198 s → 112 s. Windows 301 s → 250 s, and it failed review_rounds: every window there is drawn on the CPU (Microsoft Basic Render Driver), so four apps at once slow each scenario 2–5×. With the split, the scenarios aren't the slowest job on Linux, so it buys nothing.
• rust-lld on Windows. Warm, the test build took 78 s against 70–88 s with link.exe: no gain. Adopting it costs a full rebuild, because the linker is part of Cargo's fingerprints (the first run took 47 min).
• RUST_TEST_THREADS=8. No gain on Windows (336 s against 305 s) or Linux.
• Windows Defender exclusions and Dev Drive. GitHub's runner image already turns Defender off and excludes C:\ and D:.
• sccache. Dependencies already come from the cache, and dv's own crates rebuild after every checkout (file times), which sccache doesn't change.
• Making the heavy jobs wait for actionlint and cargo-deny. It saves minutes only when those fail, and adds ~1 min to every green run, on a repo whose minutes are free.
• Larger runners (GitHub 8-core Windows $0.042/min, Blacksmith 8 vCPU $0.032/min). Both need a GitHub organization (GitHub's on the Team plan), and kylekz/diff is a personal repository.

Found on the way

tests/e2e/review_rounds.jsonl:85 also fails on Windows without --jobs: /stream/top_file reads src/lib/http.ts, not src/lib/cache.ts. That happened twice in 7 Windows runs. A flaky scenario, outside this PR.

🤖 Generated with Claude Code