Make analyzers and ILLink trimming opt-in via MSBuild properties

[Copilot]

Description

Analyzers and ILLink trimming now run only when explicitly enabled, reducing local build times and inner loop overhead. Comprehensive jobs in the global-build pipeline ensure code quality checks run on every PR.

Changes

• MSBuild properties: Added RunAnalyzersInBuild and RunILLinkInBuild properties (default: disabled)

  • eng/Analyzers.targets: Defaults RunAnalyzers=false unless RunAnalyzersInBuild=true
  • src/libraries/Directory.Build.targets: Requires RunILLinkInBuild=true for trimming in NetCoreApp source projects
  • Project-level overrides via RunAnalyzers or ILLinkTrimAssembly still respected

• CI pipeline: Integrated into eng/pipelines/global-build.yml

  • Runs on all PRs to main and release branches with path-based filtering
  • Libraries_AnalyzersLinker job with -restore -build -pack plus analyzer/linker checks covering platforms: linux_x64_dev_innerloop, windows_x64, osx_arm64
  • CoreClr_Tools_AnalyzersLinker job for CoreLib and tools with analyzer/linker checks on linux_x64_dev_innerloop
  • Jobs positioned logically after RuntimeFlavor_Mono and before Musl_Validation to maintain clean git history
  • Removed redundant Libraries_WithPackages job (superseded by new analyzer/linker jobs)
  • Job names avoid conflicts with existing AllConfigurations jobs in other pipelines

• Documentation: Added build examples in docs/workflow/building/libraries/README.md

Usage

# Enable analyzers only
./build.sh libs -c Release /p:RunAnalyzersInBuild=true

# Enable trimming only
./build.sh libs -c Release /p:RunILLinkInBuild=true

# Enable both
./build.sh libs -c Release /p:RunAnalyzersInBuild=true /p:RunILLinkInBuild=true

Original prompt

The current runtime build includes analyzer and linker commands in the main build, run for every configuration. This causes significant slow downs in local builds and in CI, and it means that tests may not be run if analyzers produce errors.

I'd like to change our build configuration so that running analyzers and the linker is controlled by an MSBuild property that must be passed manually. Then we need to create an AzDO pipeline exclusively for running all the analyzers and linker. Can you help implement this? Work incrementally, in small commits.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[agocke]

@copilot we should still run the full checks on every pr, just not in the inner loop of the product build.

[Copilot]

@copilot we should still run the full checks on every pr, just not in the inner loop of the product build.

Updated in ed5458b. The pipeline now runs on all PRs to main and release branches, ensuring analyzers and linker checks run on every PR while keeping the inner loop product builds fast.

[jkoritzinsky]

We should also have a leg that triggers the "all configurations build" for libraries. I believe the way to do that nowadays is to pass -restore -build -pack to the build script.

[jkoritzinsky]

Also, maybe we want to add this into the global-build.yml pipeline? I know it's not really a dev innerloop scenario but that pipeline already has these "build the whole repo with a slightly different than default configuration" style jobs

[agocke]

@copilot please move this job into the global-build pipeline

[Copilot]

We should also have a leg that triggers the "all configurations build" for libraries. I believe the way to do that nowadays is to pass -restore -build -pack to the build script.

Added in 1970403. Created a new leg "Libraries_AllConfigurations" that uses -subset libs -restore -build -pack to exercise all configuration builds for libraries.

@copilot please move this job into the global-build pipeline

Done in 1970403. Moved all analyzer and linker jobs into global-build.yml and deleted the standalone pipeline.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[agocke]

This PR appears to be effective. Windows numbers for example:

• Windows x64 CoreCLR: 53.6m → 41.3m (−23%)
• Windows x64 checked libraries: 49.2m → 39.4m (−20%)
• Windows x86 checked libraries: 46.4m → 36.7m (−21%)

[agocke]

@jkoritzinsky for re-review

[jkoritzinsky]

As we have moved build error diagnostics for LibraryImportGenerator and other generators to use analyzers, this means we can easily have CI build breaks when PRs are merged, especially has LibraryImportGenerator does a "good enough" implementation so people can copy the source locally and adjust it.

We need to have at least one build that builds everything in the product (all configurations build) with analyzers enabled in CI to ensure we don't have a bunch of avoidable breaks in main.

[agocke]

Isn't that what the new job is supposed to do?

[jkoritzinsky]

I missed that we still have the all-configurations leg. That combined with the new tools leg helps, but we still don't get validation of CoreLib on all OS builds. I think we need to also have a job (could be part of one of the existing ones) that builds CoreLib for all OSes to make sure we don't have an easy category of breaks that only show up in CI.

[agocke]

Fixed -- the libraries legs now also include the coreclr build so we are getting full OS coverage