Fix runtime-wasm-perf Mono job by supplying the CoreCLR browser-wasm runtime pack#131032
Closed
akoeplinger wants to merge 2 commits into
Closed
Fix runtime-wasm-perf Mono job by supplying the CoreCLR browser-wasm runtime pack#131032akoeplinger wants to merge 2 commits into
akoeplinger wants to merge 2 commits into
Conversation
…ime pack PR dotnet#130380 added the CoreCLR browser-wasm runtime pack (Microsoft.NETCore.App.Runtime.browser-wasm) to the shared wasm-tools workload manifest. As a result the Mono perf build job's `dotnet workload install wasm-tools` from the local feed fails, because the Mono build (-s mono+libs+host+packs) never produces that CoreCLR pack. Mirror the fix dotnet#130380 applied to the Wasm.Build.Tests pipelines: publish the CoreCLR browser-wasm runtime pack nuget from the wasm_coreclr build job as the BrowserWasmCoreCLRRuntimePack pipeline artifact, and make the Mono build job depend on it and download it into the local Shipping package feed before the workload install step. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ef6da291-7777-4114-9c73-05398fb2b5f6
|
Azure Pipelines: Successfully started running 5 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. |
Member
Author
|
/azp run runtime-wasm-perf |
|
Azure Pipelines: No pipelines were found matching this branch/path. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the WebAssembly performance build template to ensure the Mono browser-wasm perf job can install the wasm-tools workload from the local artifacts feed by supplying the CoreCLR browser-wasm runtime pack produced by the CoreCLR perf job.
Changes:
- Serializes the Mono browser-wasm perf job behind the CoreCLR browser-wasm perf job via an explicit
dependsOn. - Publishes the CoreCLR
Microsoft.NETCore.App.Runtime.browser-wasmruntime pack.nupkgas a dedicated pipeline artifact and downloads it into the Mono job’s localShippingfeed before workload install.
Comment on lines
+53
to
+55
| - script: >- | ||
| mkdir -p $(Build.SourcesDirectory)/artifacts/staging-coreclr-runtime-pack && | ||
| cp $(Build.SourcesDirectory)/artifacts/packages/$(_BuildConfig)/Shipping/Microsoft.NETCore.App.Runtime.browser-wasm.*.nupkg $(Build.SourcesDirectory)/artifacts/staging-coreclr-runtime-pack |
…CoreCLR pack The previous approach invoked publish-pipeline-artifacts.yml directly as a postBuildStep. global-build-job.yml forwards osGroup/archType/buildConfig/etc. to every postBuildStep template, and publish-pipeline-artifacts.yml declares typed parameters, which enforce strict validation and reject those forwarded params -> 'Unexpected parameter' pipeline compile errors. Move the publish (CoreCLR job) and download+stage (Mono job) logic into the untyped perf-wasm-prepare-artifacts-steps.yml template behind publishCoreClrRuntimePack/downloadCoreClrRuntimePack params, mirroring the structure of dotnet#131026 but using the post-dotnet#128498 pipeline-artifact tasks (PublishPipelineArtifact/DownloadPipelineArtifact) instead of the removed publish-build-artifacts.yml template and legacy DownloadBuildArtifacts@0. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ef6da291-7777-4114-9c73-05398fb2b5f6
Comment on lines
+56
to
+60
| - ${{ if eq(parameters.publishCoreClrRuntimePack, true) }}: | ||
| - 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" |
Comment on lines
+18
to
+19
| dependsOn: | ||
| - build_browser_wasm_linux_Release_wasm_coreclr |
Member
Author
|
Closing in favor of #131026, which fixes the same Note This comment was authored with the help of GitHub Copilot. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
runtime-wasm-perfpipeline's Mono build job fails at the "Install workload using artifacts" step:Root cause
#130380 added the CoreCLR browser-wasm runtime pack (
Microsoft.NETCore.App.Runtime.browser-wasm) to the sharedwasm-toolsworkload manifest. Installing the workload from the local package feed now requires that pack to be present. The Mono perf build job (-s mono+libs+host+packs) never produces it, sodotnet workload install wasm-toolsfails. The CoreCLR perf job passes because the workload install is a no-op for the CoreCLR flavor (_GetWorkloadsToInstallonly selects workloads forRuntimeFlavor == 'Mono').#130380 already handled this for the Wasm.Build.Tests pipelines (via the
includeCoreClrRuntimePackparameter inbrowser-wasm-build-tests.yml), but left theruntime-wasm-perfMono job broken.Fix
Mirror the approach used for the WBT pipelines:
wasm_coreclr) publishes the CoreCLR browser-wasm runtime pack nuget as a newBrowserWasmCoreCLRRuntimePackpipeline artifact.wasm) now depends on the CoreCLR build job and downloads that pack into its localShippingpackage feed before the workload-install step.This serializes the Mono build after the CoreCLR build (they previously ran in parallel), which is the same producer/consumer relationship the WBT pipelines already use.
Testing
This is a CI-pipeline-only change that can't be exercised locally. The logic was verified by tracing the workload-install targets (
BuiltNuGetsDir=artifacts/packages/<config>/Shipping, download lands in the feed before install, no interference with the Mono-only pack-count check inworkloads-browser.targets) and confirming thedependsOnjob name matches the generated job name. It needs aruntime-wasm-perfpipeline run to validate end to end.Note
This pull request was authored by GitHub Copilot.