#52754: build: run the Windows builds on the VM runners
Description of Change
Moves the two Windows build jobs in build.yml from the windows-amd64-16core container runners to garm-windows-x64-32core, the single-use VM runners from electron/infra#316 (one Azure D32ads_v7 per job, work tree on local NVMe, VM deleted when the job ends). Test and clang-tidy jobs are unchanged.
Comparison against main's last run on the current runners before #52745 — same DEPS, ~99.9% siso cache hits on both, so this is the runner overhead — vs this PR's CI on the VMs (rebased on #52745, which removed Zip Symbols from testing builds; ~12.6 min of the baseline column is that step, so the old runners would now be ~78 min):
| windows-x64 build job | current runners | VM runners |
|---|---|---|
| whole job | 90.3 min | 19.2 min |
| Unzip and Ensure Src Cache | 11.3 min | 3.2 min |
| Get Windows toolchain | 3.4 min | 2.3 min |
| Build Electron (siso, fully cached) | 20.4 min | 6.0 min |
| Zip Symbols | 12.6 min | — (#52745) |
| Move artifacts to upload folder | 12.6 min | 0.3 min |
| Upload Out Gen Artifacts | 10.9 min | 0.7 min |
windows-arm64: 84.4 min → 21.2 min. VM queued→job start is ~3 min (single-use D32ads_v7 per job, created on demand, deleted ~1 s after the job ends); that's included in the workflow's wall clock but not in the job times above.
Also carries the one CI-action change the VMs need: install-build-tools hardcoded ContainerAdministrator's profile for the depot_tools PATH entry; it now uses USERPROFILE, which is what build-tools installs under on both the container and the VMs (an earlier $HOME variant, #52753, broke the container). electron/infra#318/#319 have landed, so the VM configuration this targets is the committed one; the label has been running builds since this afternoon. Publish workflows are intentionally not touched yet.
Checklist
- I have built and tested this change
- I have filled out the PR description
- I have reviewed and verified the changes
Release Notes
Notes: none
Backports
Semver Impact
Semantic Versioning helps users understand the impact of updates:
- Major (X.y.z): Breaking changes that may require code modifications
- Minor (x.Y.z): New features that maintain backward compatibility
- Patch (x.y.Z): Bug fixes that don't change the API
- None: Changes that don't affect using facing parts of Electron