perf(ci): make desktop Rust caches restorable and split out GPUI

[ayagmar]

Follow-up to #2486. The CI wait there was crazy, so I looked into why and put together a fix.

Desktop CI on PRs compiled the Rust workspace from scratch every run (No cache found. on every desktop job), so Build Desktop took 41 to 90 minutes. With this change a PR's CI finishes in about 20 minutes once main has saved caches: the slowest job is 77 to 79% faster.

Results

Job	Upstream	This PR, cold	This PR, warm	Gain (warm)
Build Desktop, Linux	41 to 56 min	18 min	18 min (not cached)	56 to 68%
Build Desktop, macOS	77 to 84 min	12 min	15 min	81 to 82%
Build Desktop, Windows	69 to 90 min	22 min	13 min	81 to 86%
Build GPUI Desktop, Linux	18 to 26 min (inside Build Desktop)	27 min	7 min	62 to 73%
Build GPUI Desktop, macOS	41 to 46 min (inside Build Desktop)	44 min	19 min	54 to 58%
Build GPUI Desktop, Windows	34 to 47 min (inside Build Desktop)	48 min	12 min	64 to 74%
Clippy, macOS	9 to 33 min	9 min	4 min	56 to 88%
Clippy, Windows	18 to 24 min	11 min	8 min	56 to 67%
Slowest job	81 to 90 min	48 min	19 min	77 to 79%

Upstream runs: 38454691299, 38446218534, 38433517508. This branch on a fork, using a temporary commit that saved caches from the branch: cold, warm.

Why the cache never hit

• The Rust cache job set RUST_TARGET_TRIPLE as job env. rust-cache hashes env into the key, so main saved under one key and PRs looked up another.
• setup-js saved an ~800 MB bun cache per PR and OS, which filled the 10 GB quota and evicted everything else.
• cancel-in-progress cancelled main runs before their cache save.

Changes

• Build Desktop and GPUI save their own caches from main; the Rust cache job is gone.
• GPUI builds and tests in its own parallel job.
• Root cargo test calls use --target, so they share the debug tree with tauri build --debug --target.
• CI builds the sidecars in debug. build-desktop-binaries.sh takes an optional profile and still defaults to release.
• Clippy writes empty sidecar stubs (tauri-build only checks they exist) and reuses Build Desktop's cache.
• main runs are no longer cancelled; the bun cache is Linux-only and saved from main only.

Trade-offs

• Sidecars build in debug on PRs. A release-only break (LTO, linking) now shows up in desktop-release.yml. The release sidecar build was 16 to 21% of Build Desktop (7 to 17 minutes), and dropping it makes that cache 36 to 40% smaller (measured on the fork).
• Linux Build Desktop is not cached. All caches came to 10.97 GB, over the 10 GB quota; dropping this one frees 15% of the quota. A cache would make that job 39 to 50% faster, but it already finishes before the slowest job, so the PR's total time doesn't change.
• No bun cache on macOS/Windows. Costs 25 to 50 seconds, 3 to 6% of those jobs; keeping it needs 17% of the quota.
• Thin headroom. The caches use 95% of the quota. After a Cargo.lock change, old entries linger until evicted, so expect an occasional cold run.

Confidence Score: 5/5

This PR appears safe to merge; no actionable issues were found.

Summary

This PR moves Rust cache saves into the desktop build jobs and runs GPUI in a separate parallel job.

• Main CI builds save caches that pull-request builds can reuse.
• GPUI desktop builds and tests run beside the Tauri desktop build.
• Desktop CI builds sidecars in debug and shares those outputs with tests.

No actionable issues were found.

Acknowledged trade-offs:

• ayagmar explicitly accepts debug sidecars in CI, with release-only checks left to desktop-release.yml.
• ayagmar intentionally leaves Linux Build Desktop uncached and removes macOS/Windows Bun caches to stay within the cache quota.
• ayagmar acknowledges thin cache headroom and occasional cold runs after lockfile changes.

_{Reviews (1) · Last reviewed commit: "perf(ci): make desktop Rust caches resto..." · Reviewed by Greptile}

[vercel]

@ayagmar is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[ayagmar]

@greptileai please review

[richiemcilroy]

Hey @ayagmar, thanks so much for your PR - looks like bad timing, I've also been working on my own CI optimisations.

I've still sponsored you :) cheers!

[ayagmar]

Thanks a lot for the sponsor, I really appreciate it! I'm always happy to help out