ci(windows): switch to Ninja so sccache actually wraps cl.exe#1963
Merged
ci(windows): switch to Ninja so sccache actually wraps cl.exe#1963
Conversation
CMAKE_CXX_COMPILER_LAUNCHER is honoured by Ninja and Makefiles generators only — not by the Visual Studio / MSBuild generator that CMake picks by default on windows-latest. As a result, the sccache work in #1913 was a no-op: sccache stats from recent runs show "Compile requests: 0". The build still took ~13 min instead of the target 2-3 min on warm cache. Fix: - Add ilammy/msvc-dev-cmd to put the MSVC toolchain (cl.exe, link.exe) on PATH so Ninja can find them. - Pass -G Ninja to the cmake configure step so COMPILER_LAUNCHER is actually applied. - Drop --config Release from the build invocation (Ninja is single-config; the flag was a Visual Studio carryover). First run after this lands populates sccache for real (~12 min). Subsequent PRs hitting the same translation units should drop to the 2-3 min target. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Drop the 'build' dependency from check-windows. The Linux build was a gating step originally to avoid burning Windows runner minutes on PRs where Linux already failed, but in practice Linux passes the vast majority of PRs and the ~3 min serial wait was on every PR. Now check-windows starts as soon as check-paths resolves the conditional (~10 s into the run), in parallel with the Linux build. Wall-clock total when both pass drops from ~16 min to ~13 min today, and to ~max(3 min, sccache-warm Windows) once #1963's sccache fix populates the cache. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
GitHub Actions Cache occasionally has outages — when that happens, the sccache GHA backend can't read/write, and every compile invocation through sccache fails with "Server startup failed: cache storage failed to read". That cascades and the whole Windows build job fails even though our code is fine. Pre-flight a tiny test compile through sccache before configuring. If it fails, set healthy=false and configure CMake without the COMPILER_LAUNCHER flags — build proceeds at uncached speed but proceeds. When the outage clears the next CI run is back to normal (and warm-cache speeds once the cache populates). Adds ~15 lines. Cost: a 1-line cl.exe invocation per run (~50 ms). Benefit: outages no longer block PR merges. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The sccache work in #1913 was effectively a no-op. `sccache --show-stats` from recent runs shows:
```
Compile requests 0
Compile requests executed 0
Cache hits 0
Cache misses 0
```
Builds still take ~13 min — same as pre-#1913.
Root cause
`CMAKE_CXX_COMPILER_LAUNCHER` is honoured by Ninja and Makefiles generators only — not by the Visual Studio / MSBuild generator that CMake selects by default on `windows-latest`. Our Configure step was `cmake -B build ...` with no `-G` flag, so MSBuild ran cl.exe directly and never went through sccache.
Fix
Expected impact
The `sccache stats` step at the end of the job will now show non-zero compile requests + cache hits, which we can verify on the second run.
Test plan
🤖 Generated with Claude Code