Release Windows check is the slowest pull-request lane in the repository and the only one that builds Rust without a build cache.
Where its time goes
Mean over 4 green pull-request runs, 23m47s total:
| Step |
Time |
Share |
| Package the Windows installer and ZIP |
10m54s |
46% |
| Exercise pinned-version upgrade and uninstall |
2m48s |
12% |
| Verify automatic update end to end |
2m44s |
11% |
| Prove deterministic mid-install failure rollback |
2m36s |
11% |
| Build the version-bumped autoupdate installer |
2m03s |
9% |
| Verify the Windows release |
1m19s |
6% |
| install / setup / checkout |
~1m12s |
5% |
| Download and verify the pinned baseline |
5s |
0.3% |
Packaging is nearly half the lane on its own, and scripts/package-windows-x64.mjs:122-132 shows why it is not only TypeScript and electron-builder:
npm run build:runtime-host-peer
cargo build --manifest-path <windows sandbox launcher> --release --locked
Two Rust release builds, from cold, on windows-2025 — the slowest and scarcest runner class we use.
The gap
Every other lane that compiles Rust already caches it with Kache. This one does not:
| Workflow |
Kache references |
ci.yml |
12 |
cli-package-validation.yml |
12 |
windows-sandbox-w0.yml |
12 |
release-windows-check.yml |
0 |
windows-sandbox-w0.yml is the closest reference: same runner class, same install-action pin, same KACHE_CACHE_DIR / RUSTC_WRAPPER wiring, and a restore key already keyed on the resolved rustc version.
Scope
Add the Kache install, restore and save steps to the package job in .github/workflows/release-windows-check.yml, following the shape windows-sandbox-w0.yml already uses. Nothing about what the lane asserts should change; this is only how long its Rust half takes.
Note the cache must cover both crates the packaging script builds, not just the sandbox launcher.
Acceptance
Package the Windows installer and ZIP step time on a warm cache, reported against the 10m54s baseline above. A cold run is expected to be unchanged.- The lane still passes end to end, including
Verify the Windows release, so the cache cannot be hiding a stale artifact.
No number is promised here. The Rust share of that 10m54s has not been isolated, so the first task is to measure it — if it turns out to be small, that result is worth recording and closing on.
Context
Found while measuring #4451 / #4461. That pull request cut this lane's trigger rate from 55 to 41 of the last 200 merges and removed its most frequent false red, but deliberately did not touch how it builds — changing the build would have invalidated the reviews already on it.
Release Windows checkis the slowest pull-request lane in the repository and the only one that builds Rust without a build cache.Where its time goes
Mean over 4 green pull-request runs, 23m47s total:
Packaging is nearly half the lane on its own, and
scripts/package-windows-x64.mjs:122-132shows why it is not only TypeScript and electron-builder:Two Rust release builds, from cold, on
windows-2025— the slowest and scarcest runner class we use.The gap
Every other lane that compiles Rust already caches it with Kache. This one does not:
ci.ymlcli-package-validation.ymlwindows-sandbox-w0.ymlrelease-windows-check.ymlwindows-sandbox-w0.ymlis the closest reference: same runner class, sameinstall-actionpin, sameKACHE_CACHE_DIR/RUSTC_WRAPPERwiring, and a restore key already keyed on the resolvedrustcversion.Scope
Add the Kache install, restore and save steps to the
packagejob in.github/workflows/release-windows-check.yml, following the shapewindows-sandbox-w0.ymlalready uses. Nothing about what the lane asserts should change; this is only how long its Rust half takes.Note the cache must cover both crates the packaging script builds, not just the sandbox launcher.
Acceptance
Package the Windows installer and ZIPstep time on a warm cache, reported against the 10m54s baseline above. A cold run is expected to be unchanged.Verify the Windows release, so the cache cannot be hiding a stale artifact.No number is promised here. The Rust share of that 10m54s has not been isolated, so the first task is to measure it — if it turns out to be small, that result is worth recording and closing on.
Context
Found while measuring #4451 / #4461. That pull request cut this lane's trigger rate from 55 to 41 of the last 200 merges and removed its most frequent false red, but deliberately did not touch how it builds — changing the build would have invalidated the reviews already on it.