Add stable .NET 10 mobile SDK baseline runs

[matouskozak]

Summary

• add Android and iOS Release baseline jobs for the latest stable .NET 10 SDK
• run the .NET 10 default mobile configuration with Mono, with comments to switch to CoreCLR when the baseline moves to .NET 11
• resolve stable workloads through normal workload installation while preserving the existing latest-prerelease workload path
• update the stale .NET 10 Arcade and Helix SDK pins

Validation

• .NET 10-only mobile validation — Pixel, Galaxy, and iPhone jobs succeeded; Kusto ingestion verified
• Full mobile Release comparison — all 14 net10/net11 Release mobile jobs succeeded

[Copilot]

Pull request overview

Adds stable .NET 10 MAUI baseline coverage for mobile (Android/iOS) Release runs, and updates the MAUI workload installation path to support “stable” workloads (SDK-default manifests) alongside the existing “latest prerelease” workflow.

Changes:

• Introduces MAUI_WORKLOAD_MODE=stable support in MAUI workload setup so stable runs use SDK-default workload manifests and skip the NuGet.config merge path.
• Adds new Android and iOS Release “SDK Default Baseline” jobs for channel 10.0 (Mono runtime flavor) in the SDK perf pipeline.
• Updates .NET 10 Arcade and Helix SDK pins in global.net10.json.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/scenarios/shared/mauisharedpython.py	Adds stable workload mode and adjusts MAUI workload install/nuget-config-merge behavior based on MAUI_WORKLOAD_MODE.
global.net10.json	Updates .NET 10 Arcade/Helix SDK versions.
eng/pipelines/sdk-perf-jobs.yml	Adds new .NET 10 Release baseline jobs for MAUI Android and iOS scenarios.

Suppressed comments (2)

eng/pipelines/sdk-perf-jobs.yml:570

• The stable baseline jobs set MAUI_WORKLOAD_MODE under variables, but the scenario templates only forward runEnvVars (which becomes --run-env-vars ...). As-is, this env var likely won’t be passed to the job script/Helix run, so stable workload mode won’t actually be enabled.

        variables:
          - name: MAUI_WORKLOAD_MODE
            value: stable
        ${{ each parameter in parameters.jobParameters }}:

src/scenarios/shared/mauisharedpython.py:628

• In stable workload mode this installs the SDK’s default workload manifests, not necessarily the “latest stable” workload. The current log messages (“Installing latest stable …”) are misleading for troubleshooting and comparing baselines.

    use_stable = use_stable_maui_workload()
    install_kind = "latest stable" if use_stable else "latest"
    getLogger().info(f"########## Installing {install_kind} {workload_name} workload ##########")

    if precommands.has_workload:
        getLogger().info(f"Skipping {workload_name} installation due to --has-workload=true")
        return

    if use_stable:
        precommands.install_workload(workload_name, [])
        getLogger().info(f"########## Finished installing latest stable {workload_name} workload ##########")
        return

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[LoopedBard3]

Just to double check, we are all good with these appearing on the same .NET 10 history trends we previously had? Not having anything in the test name or RunConfig will mean these should flow the same way a non-stable run would. I think that is fine because we currently will only have stable set running .NET 10 and we are running the same tests anyways. Just something to keep in mind if we ever wanted stable trends vs non-stable trends.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

eng/pipelines/sdk-perf-jobs.yml:568

• The new SDK-default baseline job sets runtimeFlavor: mono but doesn’t set additionalJobIdentifier. Since runtimeFlavor isn’t included in the generated job name, adding an identifier keeps the iOS baseline job clearly labeled and consistent with the existing CoreCLR/Mono MAUI jobs.

        runtimeFlavor: mono # Update to coreclr when the baseline moves to .NET 11.
        codeGenType: Default
        buildConfig: Release
        variables:
          - name: MAUI_WORKLOAD_MODE

eng/pipelines/sdk-perf-jobs.yml:448

• The new SDK-default baseline job sets runtimeFlavor: mono but doesn’t set additionalJobIdentifier. In this pipeline, runtimeFlavor is not part of the generated job name/display name, so omitting additionalJobIdentifier makes this baseline job harder to distinguish from other MAUI Android jobs (and risks future naming collisions if more variants are added).

This issue also appears on line 564 of the same file.

        runtimeFlavor: mono # Update to coreclr when the baseline moves to .NET 11.
        codeGenType: Default
        buildConfig: Release
        variables:
          - name: MAUI_WORKLOAD_MODE

[matouskozak]

Just to double check, we are all good with these appearing on the same .NET 10 history trends we previously had? Not having anything in the test name or RunConfig will mean these should flow the same way a non-stable run would. I think that is fine because we currently will only have stable set running .NET 10 and we are running the same tests anyways. Just something to keep in mind if we ever wanted stable trends vs non-stable trends.

My thinking behind this PR was to have a current release stable version running (.NET X) and the new pre-release non-stable version (.NET X + 1). That way we could distinguish them and plot them side by side. Is your concern if we would have the same .NET version running with stable and non-stable concurrently?

We currently only need a baseline which customers are using (stable) and the new version which is under development so we shouldn't clash but I can add it if you think this is something we might want in the future.