Skip to content

ci: speed up the Windows jobs - #5808

Draft
ric-oliv wants to merge 2 commits into
ci/stop-installing-what-jobs-dont-usefrom
ci/speed-up-windows-jobs
Draft

ric-oliv wants to merge 2 commits into
ci/stop-installing-what-jobs-dont-usefrom
ci/speed-up-windows-jobs

Conversation

@ric-oliv

@ric-oliv ric-oliv commented Oct 25, 2026 •

Copy link
Copy Markdown
Member

Part 2 of 6 for #5806, based on #5807. The Windows jobs spent much longer than Linux in setup, restore and the MSBuild job, for two reasons, one commit each.

Build the MSBuild job on all cores. msbuild.exe builds on one node unless it gets -m, while the dotnet CLI passes -maxcpucount on its own. The MSBuild job's binlog showed 21.4 minutes on a single node. -nr:false keeps the worker nodes from staying around after the build, since nothing later in the job uses them. In #5796 the job took 26.0 minutes against 29.6 to 30.3, with the same 44 warnings and 49 packages as a single-node build.

Install .NET and NuGet packages on a faster drive. The Windows images keep .NET under C:\Program Files\dotnet, where workloads install as MSI packages, and NuGet extracts packages into the user profile on C:.

  • A new windows-dotnet-drive composite action puts .NET and the NuGet cache next to the workspace, where workloads install as plain files. On the x64 runners that's on D:.
  • The arm64 runners only have C:, so there the NuGet packages and TEMP go on a Dev Drive. Trusting a freshly mounted Dev Drive can fail with "Access is denied" while the volume is still busy, so the action retries it. If setting up the drive fails anyway, the action warns and keeps the NuGet packages next to the workspace, so the job still runs, just slower.
  • The build legs, the MSBuild job and verify-api's Windows job use it.

What #5782 and the probes #5798 and #5801 measured:

  • On win-x64, Restore went from about 5 minutes to 1, and the workload step from 338 to 100 seconds.
  • The MSBuild job's Run MSBuild step went from 23 to 24 minutes to 14.7, with only the drive.
  • On win-arm64 the job took 33.8 and 32.4 minutes with NuGet and TEMP on the Dev Drive, against 37.2 and 35.8 without it. Putting .NET or the workspace on the Dev Drive too was slower. Turning off Defender's real-time scanning saved less, because the image already excludes C:\ and D:\.

On this PR's own CI

3 runs, including #5807, against main at b41b96c. The MSBuild job took 15.3, 14.4 and 14.8 minutes against 29.5, with Run MSBuild at 10.3 to 10.6 against 22.5. win-x64's Restore took 0.8 to 1.1 minutes against 6.0, and win-arm64's 2.2 to 2.8 against 4.0. win-arm64's Setup Environment stayed at 4.7 to 5.2. The whole stack's numbers are in #5806.

#skip-changelog

@codecov

codecov Bot commented Oct 25, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.13%. Comparing base (b13062d) to head (d673987).

Additional details and impacted files
@@                            Coverage Diff                            @@
##           ci/stop-installing-what-jobs-dont-use    #5808      +/-   ##
=========================================================================
+ Coverage                                  75.53%   76.13%   +0.59%     
=========================================================================
  Files                                        514      528      +14     
  Lines                                      19172    19579     +407     
  Branches                                    3739     3829      +90     
=========================================================================
+ Hits                                       14482    14906     +424     
+ Misses                                      3811     3791      -20     
- Partials                                     879      882       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ric-oliv and others added 2 commits October 25, 2026 17:22
msbuild.exe builds on one node unless it gets -m, while the dotnet CLI
passes -maxcpucount on its own. The MSBuild job's binlog shows 21.4
minutes on one node, 12.4 of them in Build. The win-x64 leg builds the
same solution filter with dotnet build in 3 to 4.5 minutes. -nr:false
keeps the worker nodes from staying around after the build, since
nothing later in the job uses them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Windows .NET legs spent about 12 minutes in Setup Environment and
Restore, against about 4.5 on Linux. setup-dotnet installed into
C:\Program Files\dotnet, where the SDK installs workloads as MSI
packages, and NuGet extracted packages into the user profile on C:.

A new composite action installs .NET and the NuGet cache next to the
workspace, where workloads install as plain files. On the x64 runners
that's on D:. The arm64 runners have no D:, so there the NuGet packages
and TEMP go on a Dev Drive, and .NET stays next to the workspace on C:.
Trusting the new drive is retried. If setting it up fails anyway, the
step warns and keeps the NuGet packages next to the workspace, because
the drive is a speedup. Windows also stops restoring the Android test
app, which its solution filters exclude.

The build legs, the MSBuild job and verify-api's Windows job use it.
In two probes of the win-arm64 leg, the job took 33.8 and 32.4 minutes
with the Dev Drive, against 37.2 and 35.8 without it, and 36.9 with
.NET on the drive too. On its own, the step took the MSBuild job's
Run MSBuild from 23-24 to 14.7 minutes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ric-oliv
ric-oliv force-pushed the ci/speed-up-windows-jobs branch from d4f0e61 to d673987 Compare October 25, 2026 16:22
@ric-oliv
ric-oliv force-pushed the ci/stop-installing-what-jobs-dont-use branch from 692022a to b13062d Compare October 25, 2026 16:22

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