Add Rust build caching to CI

[cohogan]

Adds Swatinem/rust-cache@v2 to the publish workflow and bumps version to 0.2.2. First post-merge build is still cold; speedup starts on the second build.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[github-actions]

Claude finished @cohogan's task in 44s —— View job

---

Code Review: Add Rust build caching to CI

• Gather context and read changed files
• Review workflow changes
• Review version bump consistency
• Post review feedback

---

Verdict: Approve ✅

Clean, minimal PR. The cache step is correctly placed and the version bump is consistent across all three locations.

Workflow changes (.github/workflows/build.yml)

The Swatinem/rust-cache@v2 step is placed in the right spot — after dtolnay/rust-toolchain@stable (which it needs to detect the toolchain) and before any build steps. The workspaces: src-tauri config correctly points to the Cargo workspace root.

One minor suggestion: consider pinning to a full SHA or at least a minor version (e.g., @v2.7.8) instead of @v2 to guard against supply-chain risk on a third-party action. This is a common hardening practice, though @v2 is widely used and reasonable for a non-critical CI optimization step.

Version bump

All three locations updated consistently from 0.2.1 → 0.2.2:

• package.json:4 ✓
• src-tauri/Cargo.toml:3 ✓
• src-tauri/tauri.conf.json:4 ✓

This follows the repo's convention documented in CLAUDE.md.

Cache key considerations

Swatinem/rust-cache@v2 derives the cache key from the OS, rustc version, Cargo.lock, and Cargo.toml by default — which is the right behavior here. Since the matrix includes 4 platform variants (2× macOS targets, Ubuntu, Windows), each will get its own cache entry automatically via the runner OS component of the key. No extra key / shared-key config is needed.

No issues found. LGTM.
|