Run -mt VMR validation three times weekly

[JanProvaznik]

Runs the -mt VMR source-build validation at 04:00 UTC every Monday, Wednesday, and Friday.

The scheduled run passes only /p:DotNetBuildMT=true and always runs even when there are no new commits. Manual runs can still override extraPropertiesStage2.

Paired with dotnet/dotnet#7820, which removes the VMR repository exclusion machinery so the opt-in applies to every repository.

[Copilot]

Pull request overview

This PR updates the Azure Pipelines VMR source-build validation pipeline to run automatically on a fixed schedule, ensuring regular validation of MSBuild changes under -mt mode without requiring manual queuing.

Changes:

• Add a scheduled trigger to run at 04:00 UTC every Monday, Wednesday, and Friday (on main), with always: true.
• Update the default stage2 property set to use MSBuildMTExcludedReposOverride=noexclusion while keeping manual overrides via extraPropertiesStage2.

[JanProvaznik]

@ViktorHofer do you think this is an acceptable resource drain?

[github-actions]

Review: Run -mt VMR validation three times weekly

Scope: CI/infrastructure change only — no product code impact. Two logical changes bundled:

1. Add a cron schedule (Mon/Wed/Fri 04:00 UTC) for automated -mt VMR validation.
2. Change the default excluded repos from roslyn to noexclusion.

Findings

✅ Cron syntax 0 4 * * 1,3,5 is correct for Mon/Wed/Fri at 04:00 UTC.

✅ Documentation comment updated accurately to reflect the new trigger.

✅ Branch targeting main only is appropriate.

⚠️ always: true — This means the pipeline runs even with no new commits. For an expensive VMR source-build, this is a tradeoff worth acknowledging. If builds are long/costly, consider always: false so it only runs when there are actual changes to main. However, if the goal is to catch upstream VMR/dependency regressions (not just MSBuild changes), always: true makes sense.

❓ noexclusion sentinel value — The change from MSBuildMTExcludedReposOverride=roslyn to =noexclusion is the more interesting part. See inline comment — please confirm this is a recognized value rather than a typo or a value that would be silently treated as a repo name.

Verdict

Looks good overall. Just want confirmation on the noexclusion value semantics.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Expert Code Review (on open) for #14410 · 52.7 AIC · ⌖ 5.09 AIC · ⊞ 4.8K

Comments that could not be inline-anchored

azure-pipelines/vmr-sb-validation.yml:28

Question: Is noexclusion a recognized sentinel value for MSBuildMTExcludedReposOverride? Previously this was roslyn, meaning Roslyn was excluded from -mt validation. Changing to noexclusion implies Roslyn -mt support is now ready.

If the property simply checks for repo names in a list, an empty string or omitting the property entirely might be clearer than a magic string. Could you confirm noexclusion is handled correctly by the consuming logic?

[JanProvaznik]

⚠️ always: true — This means the pipeline runs even with no new commits. For an expensive VMR source-build, this is a tradeoff worth acknowledging. If builds are long/costly, consider always: false so it only runs when there are actual changes to main. However, if the goal is to catch upstream VMR/dependency regressions (not just MSBuild changes), always: true makes sense.

the intent is to e2e test changes in other components

the exclusion is weird but that needs to be removed later in VMR build definition...

[ViktorHofer]

Yes, this is fine

[ViktorHofer]

If we can now remove MSBuildMTExcludedReposOverride, please do so in the VMR. Thanks.