[perf][wasm] Stage CoreCLR wasm runtime pack for Mono workload install

[lewing]

Summary

Fixes the runtime-wasm-perf pipeline, which fails at "Install workload using artifacts" in the browser-wasm linux Release wasm (Mono) build job:

Version 11.0.0-ci of package microsoft.netcore.app.runtime.browser-wasm is not found in NuGet feeds ...

Root cause

#130380 ("Enable wasm-tools workload for CoreCLR WASM targets") added the CoreCLR runtime pack Microsoft.NETCore.App.Runtime.browser-wasm to the wasm-tools workload manifest. The Mono perf build (-s mono+libs+host+packs) only produces the Mono runtime pack, and packs only builds the pack matching the build's RuntimeFlavor (DotNetBuildAllRuntimePacks even explicitly excludes CoreCLR for wasm). So the Mono job's local package feed never contains the CoreCLR pack the workload now requires, and the workload install fails.

The wasm_coreclr job's install "succeeds" only because _GetWorkloadsToInstall lists workloads solely when RuntimeFlavor == Mono, making its install a no-op.

#130380 already solved this for the main/extra-platforms CI by adding a separate CoreCLR build + downloading its runtime pack into the workload-install job (includeCoreClrRuntimePack). The perf pipeline was never given the same treatment.

Fix

The perf pipeline already builds both flavors in two jobs, so this reuses the existing CoreCLR pack instead of duplicating a build — mirroring the #130380 pattern:

• perf-wasm-prepare-artifacts-steps.yml — two opt-in parameters:
  • publishCoreClrRuntimePack: the CoreCLR job publishes its Microsoft.NETCore.App.Runtime.browser-wasm nupkg as artifact BrowserWasmCoreCLRRuntimePack_$(_hostedOs).
  • downloadCoreClrRuntimePack: the Mono job downloads it and stages it into artifacts/packages/Release/Shipping/ before the workload install.
• perf-wasm-build-jobs.yml — wasm_coreclr sets publishCoreClrRuntimePack: true; the wasm (Mono) job sets downloadCoreClrRuntimePack: true and dependsOn: build_browser_wasm_linux_Release_wasm_coreclr.

The staged CoreCLR pack doesn't interfere with the Mono job's existing _GetRuntimePackNuGetsToBuild logic (which only matches Microsoft.NETCore.App.Runtime.Mono.*), and only the net11/Current manifest requires this pack, so the 11.0.0-ci pack from the same commit satisfies it.

Tradeoff

The Mono build now depends on the CoreCLR build (previously parallel), adding wall-clock to this PR-triggered sanity pipeline. The alternative — building clr inside the Mono job — doesn't work cleanly because no single build produces both wasm runtime packs, and duplicating the full CoreCLR build is heavier. The download approach matches the established #130380 pattern.

Note

This PR was generated with the assistance of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).
10 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates the WASM perf pipeline templates so the Mono browser-wasm job can successfully install the wasm-tools workload when its manifest requires the CoreCLR Microsoft.NETCore.App.Runtime.browser-wasm runtime pack by staging that pack from the existing CoreCLR build job’s artifacts.

Changes:

• Add opt-in template parameters to (a) publish the CoreCLR browser-wasm runtime pack as a standalone build artifact and (b) download + stage it into the Mono job’s local packages feed before workload installation.
• Make the Mono browser-wasm perf job depend on the CoreCLR browser-wasm perf job and enable the new download/publish knobs accordingly.

Reviewed changes

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

File	Description
eng/pipelines/performance/templates/perf-wasm-prepare-artifacts-steps.yml	Adds conditional download/staging of the CoreCLR runtime pack before workload install, and conditional publishing of the CoreCLR runtime pack artifact.
eng/pipelines/performance/templates/perf-wasm-build-jobs.yml	Wires job dependency + enables the new publish/download parameters for the CoreCLR and Mono perf jobs.

[akoeplinger]

I pushed a commit here that migrates the CoreCLR runtime pack publish/download to the pipeline-artifact tasks.

Heads up: this branch predates the merge of #128498 (PublishBuildArtifacts -> PublishPipelineArtifact), which deleted eng/pipelines/common/templates/publish-build-artifacts.yml and moved everything to pipeline artifacts. As-is, the branch referenced that now-removed template and the legacy DownloadBuildArtifacts@0 task, so it would fail to compile / hit the wrong artifact store on current main.

The commit swaps:

• publish-build-artifacts.yml -> publish-pipeline-artifacts.yml (PathtoPublish -> targetPath)
• DownloadBuildArtifacts@0 -> DownloadPipelineArtifact@2 (downloadPath -> targetPath; pipeline-artifact download does not nest under the artifact name, so the nupkgs are copied directly from the target path)

I validated the same change compiles cleanly on a parallel PR (runtime-wasm-perf produced 0 validation errors and started the build jobs), so this should get your PR past the YAML compile stage. Feel free to squash/adjust wording as you like.

Note

This comment and the pushed commit were authored with the help of GitHub Copilot.

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (1)

eng/pipelines/performance/templates/perf-wasm-prepare-artifacts-steps.yml:60

• The publishCoreClrRuntimePack staging script will succeed even if no matching runtime-pack .nupkg exists (GNU find exits 0 with no matches), which can publish an empty artifact and push the failure to the downstream Mono job with a less actionable error. It would be better to fail this CoreCLR job step immediately when the pack is missing.

    - script: >-
        mkdir -p $(Build.SourcesDirectory)/artifacts/staging-coreclr-runtimepack &&
        find $(Build.SourcesDirectory)/artifacts/packages/${{ parameters.configForBuild }}/Shipping -maxdepth 1 -name 'Microsoft.NETCore.App.Runtime.browser-wasm.*.nupkg' -not -name '*.symbols.nupkg' -exec cp {} $(Build.SourcesDirectory)/artifacts/staging-coreclr-runtimepack \;
      displayName: "Stage CoreCLR runtime pack for workload"

[github-actions]

Workflow state for the Holistic Review Orchestrator.

{
  "version": 5,
  "last_dispatched_commit": "1f4990e4beca963600885dc032de67a69fafdac5",
  "last_dispatched_base_ref": "main",
  "last_dispatched_base_sha": "7b783ab54922b9faef6a625a0f4326ca803051f0",
  "last_reviewed_commit": "1f4990e4beca963600885dc032de67a69fafdac5",
  "last_reviewed_base_ref": "main",
  "last_reviewed_base_sha": "7b783ab54922b9faef6a625a0f4326ca803051f0",
  "last_recorded_worker_run_id": "29690739489",
  "review_attempt_commit": "",
  "review_attempt_base_ref": "",
  "review_attempt_count": 0,
  "max_review_attempts": 5,
  "review_history_format": "holistic-review-disclosure-v1",
  "review_history": [
    {
      "commit": "1f4990e4beca963600885dc032de67a69fafdac5",
      "review_id": 4730927215
    }
  ]
}

[github-actions]

Holistic Review

Motivation: The runtime-wasm-perf pipeline fails at "Install workload using artifacts" in the Mono browser-wasm linux Release wasm job. #130380 added the CoreCLR Microsoft.NETCore.App.Runtime.browser-wasm runtime pack to the wasm-tools workload manifest, but a Mono-only build (-s mono+libs+host+packs) never produces that pack, so the local feed can't satisfy the 11.0.0-ci requirement. This PR restores the perf pipeline by staging the CoreCLR pack, mirroring the fix #130380 already applied to CI.

Approach: Two opt-in template parameters are added to perf-wasm-prepare-artifacts-steps.yml. publishCoreClrRuntimePack makes the existing wasm_coreclr job publish its runtime-pack nupkg as pipeline artifact BrowserWasmCoreCLRRuntimePack_$(_hostedOs). downloadCoreClrRuntimePack makes the Mono job download that artifact and copy the nupkg into artifacts/packages/Release/Shipping/ before the workload install. The Mono job gains dependsOn: build_browser_wasm_linux_Release_wasm_coreclr. This reuses the pack already built by the parallel CoreCLR job rather than duplicating a full clr build inside the Mono job.

Summary: The change is well-scoped, correct, and consistent with existing conventions. The hardcoded dependency job name matches the build_{osGroup}{osSubgroup}_{archType}_{hostedOs}_{buildConfig}_{nameSuffix} format produced by global-build-job.yml, and the $(_hostedOs) artifact-name casing matches the variable defined in xplat-setup.yml and used throughout the wasm pipelines. Both new parameters default to false, so no other consumer of the shared template is affected. The publish step correctly excludes *.symbols.nupkg, and staging happens after the build in postBuildSteps, so the Shipping directory exists. The accepted tradeoff of serializing the Mono job behind the CoreCLR job is reasonable and documented. As noted in the description, the hardcoded dependsOn job name is a minor maintainability coupling that would silently break if the CoreCLR job's matrix parameters changed, but that matches existing patterns in these templates and is acceptable. No functional issues found. Since this only touches pipeline YAML, correctness will ultimately be confirmed by a green runtime-wasm-perf run.

Verdict: LGTM.

Note

This review was generated by this repository's Holistic Review agentic workflow to complement the built-in Copilot review.

Generated by Holistic Review · 58.5 AIC · ⌖ 10.5 AIC · ⊞ 10K