Skip to content

ci: build the MSBuild job on all cores - #5796

Draft
ric-oliv wants to merge 2 commits into
mainfrom
ci/run-msbuild-job-in-parallel
Draft

ric-oliv wants to merge 2 commits into
mainfrom
ci/run-msbuild-job-in-parallel

Conversation

@ric-oliv

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

Copy link
Copy Markdown
Member

The MSBuild job runs msbuild.exe without -m, so it builds the whole Windows solution filter on a single node. The dotnet CLI passes -maxcpucount on its own, which is why the .NET legs already use every core.

From the job's binlog on #5793:

  • msbuild ran 21.4 minutes on 1 node: Restore 8.2, Build 12.4 and Pack 0.3.
  • 5.8 of the Build minutes are 175 dotnet workload list calls from OnlyTargetInstalledWorkloads in Directory.Build.targets, one per project and target framework, all waiting on each other.
  • The .NET (win-x64) leg builds the same filter with dotnet build in 3 to 4.5 minutes.

#4300 added this job to catch build breaks that only happen in Visual Studio, like RuntimeInformation.RuntimeIdentifier failing under .NET Framework MSBuild. With -m it's still the same MSBuild building the same projects, and Visual Studio builds in parallel too.

The job took 22.8 to 29.5 minutes on the last 6 runs, so with the other open CI PRs it would be the next job to hold up the build workflow.

-m also turns on node reuse, which leaves MSBuild's worker processes running after the step. Nothing later in the job uses them, so the command passes -nr:false too.

Measured on the first run, against 3 runs from the same evening without -m:

Without -m This PR
MSBuild job 29.6 to 30.3 min 26.0
Run MSBuild step 23.1 to 23.6 18.4
Nodes in the binlog 1 4
Build target 12.4 8.3
Restore target 8.2 8.8
  • The Build target got 4 minutes faster, not the 8 I expected. Its last 2.5 minutes are Sentry.Samples.Maui for Android on a single node, which ci: build the app samples in their own job #5783 moves out of this solution filter.
  • Restore didn't change, because NuGet still extracts the packages into the user profile on C:. ci: install .NET and NuGet packages on a faster drive on Windows #5782 now moves them next to the workspace for this job too, and on its own run the step took 14.7 minutes.
  • With both, I expect the job to take about 12 to 13 minutes.
  • The build output is the same as a run without -m from the same evening: 44 warnings with the same codes, no errors, and the same 49 packages.

#skip-changelog

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.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@codecov

codecov Bot commented Oct 24, 2026 •

Copy link
Copy Markdown

Codecov Report

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

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5796   +/-   ##
=======================================
  Coverage   76.13%   76.13%           
=======================================
  Files         528      528           
  Lines       19579    19579           
  Branches     3829     3829           
=======================================
+ Hits        14906    14907    +1     
+ Misses       3791     3790    -1     
  Partials      882      882           

☔ 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.

With -m, msbuild.exe also reuses its worker nodes and leaves them
running after the build. Nothing later in the job uses them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

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