Use dotnet-public feed for CI workloads

[jonathanpeppers]

Azure DevOps workload installation currently reaches api.nuget.org, causing CFSClean network-isolation violations.

Define the dnceng dotnet-public feed as the shared workload source and use it for both dotnet workload update and dotnet workload install.

[Copilot]

Pull request overview

This PR updates the Azure DevOps CI environment setup to install .NET workloads from the dnceng dotnet-public feed instead of reaching api.nuget.org, addressing CFSClean network-isolation violations.

Changes:

• Introduce a shared dotnetWorkloadSource variable pointing at the dnceng dotnet-public feed.
• Update CI workload installation commands (dotnet workload update/install) to use $(dotnetWorkloadSource).

Reviewed changes

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

File	Description
build/ci/variables.yml	Adds dotnetWorkloadSource variable for the dnceng dotnet-public workload feed.
build/ci/setup-environment.yml	Switches workload update/install commands to use the shared workload source variable.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[jonathanpeppers]

@dalexsoto review

[dalexsoto]

The dotnet-public switch silently downgrades the workload set used to build shipped packages. With SDK 10.0.400, Microsoft.NET.Workloads.10.0.400 is unavailable on dotnet-public, so workload installation exits successfully after falling back to older bundled manifests. Build 1550944 resolves Android 36.1.2 instead of 36.1.69 and MAUI 10.0.0/9.0.111 instead of 10.0.20/9.0.120, including the net10 artifacts produced and signed by this pipeline. Keep the compliant dotnet-public feed, but use/pin the newer loose manifests (or a rollback file) and add an explicit resolved-version assertion so future workload-set gaps cannot pass silently.

[jonathanpeppers]

/azp run

[azure-pipelines]

Azure Pipelines:
No pipelines were found matching this branch/path.

[jonathanpeppers]

Addressed in 0aa8000. CI now checks the resolved Android manifest after workload installation and fails when it is below 36.1.69. This is a minimum-version check, so newer mirrored workload sets continue to upgrade normally.

[dalexsoto]

The Android minimum-version assertion prevents the previously observed Android downgrade, but it does not protect the MAUI manifests that also downgraded. In loose-manifest mode Android and MAUI resolve independently, so Android 36.1.69 can pass while maui-android remains at 10.0.0 and its net9 SDK/templates at 9.0.111. Please also assert maui-android >= 10.0.20 (and its expected workload-set/manifest mode, or equivalently pin an acceptable workload set) so the full shipped/tested workload surface cannot silently regress.

[jonathanpeppers]

. Please also assert maui-android >= 10.0.20

this repo doesn't even use maui

[dalexsoto]

The maintainer clarification is supported by the pipeline: this repository does not consume the MAUI workload, so the prior MAUI minimum-version concern is not applicable.