Repository navigation
Conversation
This was referenced Oct 25, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. 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. 🚀 New features to boost your workflow:
|
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
force-pushed
the
ci/speed-up-windows-jobs
branch
from
October 25, 2026 16:22
d4f0e61 to
d673987
Compare
ric-oliv
force-pushed
the
ci/stop-installing-what-jobs-dont-use
branch
from
October 25, 2026 16:22
692022a to
b13062d
Compare
This branch has not been deployed
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
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.
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.exebuilds on one node unless it gets-m, while thedotnetCLI passes-maxcpucounton its own. The MSBuild job's binlog showed 21.4 minutes on a single node.-nr:falsekeeps 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 onC:.windows-dotnet-drivecomposite action puts .NET and the NuGet cache next to the workspace, where workloads install as plain files. On the x64 runners that's onD:.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.What #5782 and the probes #5798 and #5801 measured:
C:\andD:\.On this PR's own CI
3 runs, including #5807, against
mainat 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