Add pipeline to validate source-build stage1+2 builds from within runtime

[jkoritzinsky]

Fixes #122998

This creates a separate pipeline for such validation as we don't want to block builds on failures as sometimes a failure is expected. As a result, I don't think we want to add this to Build Analysis. If we want to handle these sorts of expected failures via Build Analysis, I can merge this into the global-build.yml pipeline.

Remove the old source-build jobs as the VMR validation supercedes such validation.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR adds a new dedicated pipeline for validating VMR (Virtual Monolithic Repository) source-build stage1 and stage2 builds from within the runtime repository. This allows for non-blocking validation of source-build scenarios that may occasionally fail as expected, without impacting regular PR builds.

Key changes:

• Adds new vmr-build-pr.yml pipeline that triggers on runtime PRs and runs VMR verification
• Removes legacy source-build jobs from runtime.yml (CentOS.9 and NonexistentRID validation)
• Removes portable source-build job from global-build.yml (Linux_x64 validation)

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
eng/pipelines/vmr-build-pr.yml	New pipeline that validates source-build stage1 and stage2 via VMR template, with appropriate path exclusions for docs, markdown, and Mono
eng/pipelines/runtime.yml	Removes the SourceBuild stage containing CentOS.9 and NonexistentRID validation jobs that are now superseded by VMR validation
eng/pipelines/global-build.yml	Removes portable Linux x64 source-build job template that is now superseded by VMR validation

[jkotas]

we don't want to block builds on failures as sometimes a failure is expected.

Hmm, I have not realized that this still suffers from the intra-version breaking change problem.

Do we expect that this will run by default in the CI? Or is this going to be optional?

[jkoritzinsky]

I currently have it configured to run by default on PRs that match the paths. However, we can easily adjust this to only run on explicit trigger (that's something I'd have the pipeline configured with by the infra team when creating the pipeline).

[jkotas]

I currently have it configured to run by default on PRs that match the paths.

We can give it a try. We need a comment somewhere that says this is expected to fail on intra-version breaking changes, and it is ok to disable this pipeline in that case temporarily.

[jkotas]

To validate that it actually works as expected, can you temporarily introduce the Mutex bug that we have seen in the VMR to see whether this leg would be capable of catching it?

[jkoritzinsky]

I currently have it configured to run by default on PRs that match the paths.

We can give it a try. We need a comment somewhere that says this is expected to fail on intra-version breaking changes, and it is ok to disable this pipeline in that case temporarily.

I'll add a comment on the top of the YAML and in the docs if I find a good spot.

To validate that it actually works as expected, can you temporarily introduce the Mutex bug that we have seen in the VMR to see whether this leg would be capable of catching it?

Sounds good I'll temporarily reuse one of the other pipelines (global-build.yml) to get it to run in this PR as we haven't created the new pipeline yet (requires the PR to be merged first because of AzDO limitations).

[jkoritzinsky]

@NikolaMilosavljevic it looks like the VMR is not applying SBRP patches when we run the VMR validation from a repo other than SBRP (the failure is due to this patch missing even though it exists in the VMR commit that's being used: https://github.com/dotnet/dotnet/blob/01877d7766376604520664f3c9b4853728a37bfb/src/source-build-reference-packages/src/externalPackages/patches/azure-activedirectory-identitymodel-extensions-for-dotnet/0002-Fix-assembly-version-calculation-in-2026.patch