ci: cache cargo output and stop redundant runs

[PathGao]

What the measurement said

The Linux build-test job of run 31382758646 took 12m14s:

step	time
run cargo test (debug compile)	2m31s
Build app (release compile)	7m57s
everything else	1m46s

86% of the job is Rust compilation. No workflow in this repository cached any cargo output, so every run recompiled the whole dependency graph from scratch, on every runner.

What this changes

1. Swatinem/rust-cache@v2 in all three workflows, after the toolchain install, pointed at workspaces: src-tauri — that is the cargo workspace root, and without naming it the action looks for Cargo.lock at the repository root and caches nothing.

The action's automatic key covers the job id, the rustc release/host and a hash of the Cargo files. That is not enough for either matrix, so both get an explicit key:

• test_build.yml — all three entries share the job id build-test, leaving the rustc host as the only discriminator, and the target list the matrix varies never enters the key. Keyed on matrix.os-name.
• build.yml — the two windows-latest entries share the job id and the rustc host, differing only in arch. Without a key the ARM64 job would restore the x64 job's target directory. Keyed on matrix.os-matrix.arch.

2. concurrency with cancel-in-progress in test.yml, the shape test_build.yml already has. Grouped on github.ref, which is refs/pull/<n>/merge under the pull_request trigger and refs/heads/master under the push trigger, so the two can never cancel each other.

One deliberate deviation from a plain cancel-in-progress: true: it is ${{ github.event_name == 'pull_request' }}. The push trigger exists precisely so that a commit reaching master without ever having been a pull request is still tested — the comment above it says so. Cancelling one master run because a second commit landed would leave the first commit untested, putting that hole straight back. Pull request branches, which are where the redundant runs actually pile up, cancel as normal.

3. paths-ignore on test_build.yml's pull_request trigger — **.md, pics/**, .github/ISSUE_TEMPLATE/**.

I did make this change, because I could confirm it is safe. Two independent checks, both at time of writing:

• repos/sftwrdotdev/Markpad/branches/master reports protected: true with required_status_checks.contexts: [] and checks: [].
• gh pr checks --required reports "no required checks" on both open pull requests (fix(find): re-focus the preview find bar on a repeated Cmd/Ctrl+F #560, fix(release): make the recovery path usable, and stop promising updates that do not exist #566).

So build-test is not a required status check, and a pull request whose paths are all ignored is not left waiting on a job that never starts. If build-test is ever made required, this filter has to go in the same change — the reasoning is written into the workflow so that cannot happen quietly.

Why it is safe on the merits: no Markdown file is bundled as a resource (tauri.conf.json has no resources key), so documentation cannot change what the three platforms compile. The frontend suites that read samples/*.md as fixtures still run on every pull request through test.yml, which has no path filter — that job also has to keep running because releaseWorkflow.test.ts asserts on README.md, RELEASING.md and the workflow files themselves, so a docs-only pull request can genuinely break it.

samples/** is deliberately not in the list, though it was on the table. It holds only .md files today, so **.md already covers it; naming the directory would additionally drop a future non-Markdown fixture out of the matrix without anyone noticing.

What I cannot promise

• The speedup depends on the cache hit rate, which cannot be known before the caches exist. Treat the numbers above as what is being attacked, not as what will be saved. The next pull request is what measures it.
• test_build.yml's cache is the weaker one. A branch can only restore caches written on itself or on the base branch, and this workflow has no push trigger — its caches are only ever written on pull request branches. So the first run of a new pull request is still a cold compile; later pushes to the same branch are the ones that hit. Only test.yml runs on push to master, which is what seeds a fresh branch at all. Giving test_build.yml a master trigger, or a shared-key with test.yml, would change that — both have costs and are a call for you, not for this pull request.
• The per-repository cache limit is 10 GB, and this may strain it. Three platforms × two profiles (debug for cargo test, release for Build app) in test_build.yml, plus four more entries in build.yml. Eviction is least-recently-used, so the rarely-run release caches from build.yml could plausibly push out the pull-request caches that actually matter. If that shows up, dropping rust-cache from build.yml is the first thing to try — it is a workflow_dispatch-only workflow and does nothing for pull request latency.

Not done

build.yml still has no cache: npm on its setup-node steps, unlike the two test workflows. Left alone: it is release-only, so it does not affect pull request time, and it is outside what was measured.

Testing

• npm test — 960 pass, 0 fail. (releaseWorkflow.test.ts reads all three of these files as text; nothing it asserts on was touched.)
• npm run check — 674 files, 0 errors, 0 warnings.
• All three workflows re-parsed as YAML to confirm paths-ignore and concurrency sit where intended.

🤖 Generated with Claude Code