[release/10.0.3xx] Source code updates from dotnet/dotnet

[dotnet-maestro]

Note

This is a codeflow update. It may contain both source code changes from
the VMR
as well as dependency updates. Learn more here.

This pull request brings the following source code changes

From https://github.com/dotnet/dotnet

• Subscription: bbf9aa7e-217b-4275-99d1-5f23eb747967
• Build: 20260126.8 (298863)
• Date Produced: January 26, 2026 2:03:56 PM UTC
• Commit: 3b3cc2b93b356d46a6fb36768479ea53515fc2cd
• Commit Diff: f962f7e...3b3cc2b
• Branch: release/10.0.3xx

Updated Dependencies

• From 10.0.0-beta.26070.115 to 10.0.0-beta.26076.108
  • Microsoft.DotNet.Arcade.Sdk

Associated changes in source repos

• dotnet/fsharp@966a2c0...f40f00d
• d6f7f02...abfb2b9

Diff the source with this PR branch

darc vmr diff --name-only https://github.com/dotnet/dotnet:3b3cc2b93b356d46a6fb36768479ea53515fc2cd..https://github.com/dotnet/templating:darc-release/10.0.3xx-95c4fe45-7bdf-4be2-9a2a-bf5a9bc1b854

[MiYanni]

This will break the build. We need to wait until the Arcade version in the 10 version of Arcade properly flows to the VMR and then back into this PR. CC @MichaelSimons

[dsplaisted]

This will break the build. We need to wait until the Arcade version in the 10 version of Arcade properly flows to the VMR and then back into this PR

@MichaelSimons @MiYanni Has this happened? Can we merge this PR?

[MiYanni]

Yeah, you cannot run 1es-mariner-2 in CI currently (for this repo). There was a separate discussion on it, but Sean ended up hotfixing it here to fix the build: #9736

But this change has occurred in Arcade at this point. But we cannot merge this PR reverting that hotfix or CI builds will immediately stop working. VMR needs the right Arcade version to flow to it so it can flow here, so this hotfix won't be reverted.

[MiYanni]

Yeah, it is correct in release/10.0 for Arcade here: https://github.com/dotnet/arcade/blob/release/10.0/eng/common/core-templates/job/source-build.yml#L66

It has to be that value/version that flows to the VMR and then flows back here.

[marcpopMSFT]

@MichaelSimons we disabled source build in main. Can we do all 10+ branches as well?

I know we still need these for 8/9.

[MiYanni]

@marcpopMSFT Why is it taking so long for Arcade 10 updates to flow into this PR? Is something wrong with the flow from Arcade 10 to VMR to templating? The change we need is over 3 weeks old...

[marcpopMSFT]

Trying darc trigger-subscriptions --id bbf9aa7e-217b-4275-99d1-5f23eb747967 --force to see if that helps.

[marcpopMSFT]

@premun even after a force on the subscription, no new flows came through. Is there a bug in maestro or is this PR out of sync somehow blocking the backflow?

[premun]

@marcpopMSFT I will have a look. Force-triggering should work. In the meantime, it's also possible to close this one and let a new one re-open (if there are no manual changes which I don't see here)

[premun]

The problem seems to be that the --force does not override the block described in #9754 (comment). I logged dotnet/arcade-services#5908 and I would suggest closing here and re-triggering.

[DonnaChen888]

Known issue dotnet/sdk#51574.

[dotnet-maestro]

Important

While this PR was open, the source repository has received code changes from this repository (an opposite codeflow merged).
To avoid complex conflicts, the codeflow cannot continue until this PR is closed or merged.

You can continue with one of the following options:

• Ignore this and merge this PR as usual without waiting for the new changes.
  Once merged, Maestro will create a new codeflow PR with the new changes.
• Close this PR and wait for Maestro to open a new one with old and new changes included.
  You will lose any manual changes made in this PR.
  You can also manually trigger the new codeflow right away by running:

  darc trigger-subscriptions --id bbf9aa7e-217b-4275-99d1-5f23eb747967
  

• Force a codeflow into this PR at your own risk if you want the new changes.
  User commits made to this PR might be reverted.

  darc trigger-subscriptions --id bbf9aa7e-217b-4275-99d1-5f23eb747967 --force
  

💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance.

[marcpopMSFT]

Closing and retriggering per Premek as all of the commits are maestro or merges.

[marcpopMSFT]

@DonnaChen888 I noticed a lot of merge commits. I assume you were doing that to retrigger the pipelines. Do you know if the UI had the rebase option when you were doing that as if you're using the Update Branch button, I'd prefer a rebase so we don't get extra commits.

Also, if there aren't any changes to the branch that are going to fix the problem and it's just test flakiness, it's probably better to just rerun the pipeline rather than remerge (that's my recommendation for templating where generally it's test flakiness rather than other changes needed). Makes sense?

You can rerun tests through GitHub on the Checks tab or in the Azure DevOps pipeline or through an "/azp run templating-ci" command (different for each repo).

[DonnaChen888]

@DonnaChen888 I noticed a lot of merge commits. I assume you were doing that to retrigger the pipelines. Do you know if the UI had the rebase option when you were doing that as if you're using the Update Branch button, I'd prefer a rebase so we don't get extra commits.

Also, if there aren't any changes to the branch that are going to fix the problem and it's just test flakiness, it's probably better to just rerun the pipeline rather than remerge (that's my recommendation for templating where generally it's test flakiness rather than other changes needed). Makes sense?

You can rerun tests through GitHub on the Checks tab or in the Azure DevOps pipeline or through an "/azp run templating-ci" command (different for each repo).

I used GitHub’s Update branch button to retrigger CI. Thanks for the reminder — going forward, if it’s just test flakiness I’ll rerun the checks/pipeline instead; and if the branch really needs updating, I’ll prefer a rebase to avoid extra merge commits.