Skip to content

CI: give Windows a persistent Cargo target and enable sccache - #5946

Open
jdetter wants to merge 6 commits into
masterfrom
tars/windows-cache-parity
Open

jdetter wants to merge 6 commits into
masterfrom
tars/windows-cache-parity

Conversation

@jdetter

@jdetter jdetter commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

Description of Changes

Disclaimer: The PR contents and most of the description were written by AI but reviewed by me before opening for review.

Make Windows self-hosted runners reuse the warmed Cargo target baked into the runner image:

  • use C:/actions-runner/_work/target, outside the checkout directory;
  • enable Windows sccache and report its statistics;
  • keep GitHub-hosted windows-latest, Linux, and macOS behavior unchanged.

The image-warming implementation remains in infra PR 1349 for now and is expected to move into a shared cross-platform Cargo command. This PR only consumes the resulting cache layout, so that implementation change will not require another workflow change.

Performance

Compared with the median of three successful master runs, the vm26 staging qualification run showed:

  • Upload build artifacts: 5m48s → 3m15s (44.0% faster)
  • Sum of six Windows job times: 53m23s → 44m24s (16.8% faster; 8m59s saved)
  • Estimated production critical path: 22m29s → 18m30s (17.7% faster)

sccache hit rates were only 0.23%–2.63%; the benefit comes primarily from avoiding compilation through the warmed Cargo target. Results are from one staging run versus three-run production medians, so smaller differences may be normal runner variance.

API and ABI breaking changes

None.

Rollback safety impact

n/a

Expected complexity level and risk

1 — low risk. CI configuration only; an image without the warm cache falls back to a cold but working build.

Testing

  • .github/workflows/ci.yml parses successfully
  • All six Windows jobs passed on vm26: Actions run 35128480324
  • Temporary staging labels removed; final jobs target spacetimedb-windows-runner
  • Current PR CI rerun completes successfully on the final commit

Windows CI rebuilds everything from scratch on every run for one reason: the
set-cargo-target-dir anchor sends Linux to $HOME/actions-runner/_work/target,
outside the workspace, and everything else to $GITHUB_WORKSPACE/target --
which checkout wipes each run. Windows also never had sccache enabled at all.

Point Windows at C:/actions-runner/_work/target and enable sccache there,
mirroring the Linux setup already on master. The Windows branch is gated on
the runner work directory existing, so GitHub-hosted windows-latest jobs keep
their current workspace-local behaviour.

RUSTC_WRAPPER is set to an explicit C:/sccache/sccache.exe rather than the
result of `command -v`: these steps run under Git Bash, whose `command -v`
returns an MSYS path (/c/sccache/sccache.exe) that Cargo, a native Windows
process, cannot execute. The `command -v` guard is kept only to detect
whether the runner image was warmed, so an unwarmed image degrades to a cold
but working build instead of failing.

The Windows-only actions/cache entries for rusty_v8 and vendored OpenSSL are
deliberately left in place for this iteration.

Requires a runner image warmed by warm-cache-windows.ps1 in
clockworklabs/infra. Without it these paths are simply empty and builds
behave as they do today.
@jdetter
jdetter marked this pull request as draft September 16, 2026 04:35
Points upload-build-artifacts-windows, smoketest_build_windows and
smoketest_partitions_windows at spacetimedb-windows-runner-staging so this PR
can be qualified against runner image vm26, which carries the warmed sccache
store and dependency-only Cargo target.

This commit exists only to measure the effect and MUST be reverted before
merge. Leaving it in would send all production Windows CI to the staging pool.

The windows-latest matrix in the update-flow job is deliberately untouched --
it runs on GitHub-hosted runners and has no warmed image.

Revert with:
  git revert <this commit>
@jdetter
jdetter marked this pull request as ready for review September 22, 2026 03:38
@jdetter
jdetter requested a review from rekhoff September 22, 2026 03:40

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant