Performance Optimization for Foundation Build Pipeline: Break down build and test stage per platform #5363
Conversation
haonanttt
changed the title
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…DK-Build-Per-Platform-Stage.yml
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
build/AzurePipelinesTemplates/WindowsAppSDK-Build-Stage-Per-Platform.yml
Outdated
Show resolved
Hide resolved
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
build/AzurePipelinesTemplates/WindowsAppSDK-PackTransportPackage-Stage.yml
Outdated
Show resolved
Hide resolved
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull Request Overview
This PR optimizes the build pipeline by breaking down the build and test stages into platform‐specific jobs, ensuring test jobs only run after their corresponding build stage has succeeded. Key changes include:
- Injecting a test matrix parameter into multiple YAML definitions.
- Splitting the unified test stage into Test_x86, Test_x64, and Test_arm64 stages.
- Introducing a new build-per-platform template that replaces portions of the existing build stage.
Reviewed Changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| build/WindowsAppSDK-Foundation-PR.yml | Injects testMatrix parameter for test stage configuration. |
| build/WindowsAppSDK-Foundation-Official.yml | Passes testMatrix parameter to the test stage. |
| build/WindowsAppSDK-Foundation-Nightly.yml | Passes testMatrix parameter to the test stage. |
| build/ProjectReunion-BuildFoundation.yml | Adds testMatrix parameter for platform-specific testing. |
| build/AzurePipelinesTemplates/WindowsAppSDK-Test-Stage.yml | Splits the Test stage into three platform-specific stages using the new parameter. |
| build/AzurePipelinesTemplates/WindowsAppSDK-RunTestsInPipeline-Job.yml | Updates the test job to use a filtered testMatrix keyed by platform. |
| build/AzurePipelinesTemplates/WindowsAppSDK-Publish-Stage.yml | Adjusts dependencies to account for the new test stage splits. |
| build/AzurePipelinesTemplates/WindowsAppSDK-PackTransportPackage-Stage.yml | Updates build dependencies to include new build stage names. |
| build/AzurePipelinesTemplates/WindowsAppSDK-Build-Stage.yml | Transitions build jobs to use the new per-platform build template. |
| build/AzurePipelinesTemplates/WindowsAppSDK-Build-Per-Platform-Stage.yml | New template that defines build stages per platform with associated parameters. |
Comments suppressed due to low confidence (2)
build/AzurePipelinesTemplates/WindowsAppSDK-Build-Per-Platform-Stage.yml:16
- [nitpick] Ensure that the generated stage name using 'Build_{buildPlatform}' is consistent with all other pipeline references and related documentation for clarity.
stage: ${{ format('Build_{0}', parameters.buildPlatform) }}
build/AzurePipelinesTemplates/WindowsAppSDK-Build-Stage.yml:67
- Verify whether legacy job definitions (e.g. BuildFoundation_release_anycpu) are still required after transitioning to the new per-platform build template. Removing redundant jobs can help avoid duplicate builds.
# extract BuildFoundation and BuildMRT into WindowsAppSDK-Build-Stage-Per-Platform.yml.
| strategy: | ||
| matrix: ${{ parameters.testMatrix }} | ||
| matrix: $[ dependencies.FilterMatrix.outputs['setFilteredMatrixStep.filteredMatrixJson'] ] |
There was a problem hiding this comment.
Ensure that the JSON output from the FilterMatrix step is correctly parsed as an object for the matrix. If the value is a JSON string, consider converting it to the proper object type so that the downstream job receives the expected structure.
| matrix: $[ dependencies.FilterMatrix.outputs['setFilteredMatrixStep.filteredMatrixJson'] ] | |
| matrix: $[ fromJson(dependencies.FilterMatrix.outputs['setFilteredMatrixStep.filteredMatrixJson']) ] |
Copilot uses AI. Check for mistakes.
|
pipeline example runs: |
There was a problem hiding this comment.
Looks good overall.
This one will make the pipeline more resumable.
And with Muyuan's #5364, the performance is better.
| - script: | | ||
| md "C:\__t\NativeCompilerPrefast" | ||
| displayName: 'Creating C:\__t\NativeCompilerPrefast to prevent errors from Guardian PREfast' | ||
|
|
||
| - job: BuildFoundation_release_anycpu |
There was a problem hiding this comment.
Do you know what is this for int the past? Looks like no consumer for this result afterwards?
There was a problem hiding this comment.
I think the reason is that we wanted to build Microsoft.WindowsAppRuntime.Bootstrap.Net.csproj in AnyCPU.
It does seem like we have a consumer here
Copy-Item -path "BuildOutput\$configurationForMrtAndAnyCPU\anycpu\Microsoft.WindowsAppRuntime.Bootstrap.Net\Microsoft.WindowsAppRuntime.Bootstrap.Net.dll" -destination "$BasePath\lib\net6.0-windows10.0.17763.0"
in line 326 of
WindowsAppSDK\WindowsAppSDK\BuildAll.ps1
| strategy: | ||
| matrix: ${{ parameters.testMatrix }} | ||
| matrix: $[ dependencies.FilterMatrix.outputs['setFilteredMatrixStep.filteredMatrixJson'] ] |
There was a problem hiding this comment.
I just feel this name has too many related "verb" for "Filter"? (like filter many times)
Can we just talk what we just did here?
I think this step is "Extract matrix as json value filtering by build platform"?
Can it be like "dependecies.ExtracMatrix.outputs['filteredByBuildPlatform.valueAsJson']
Original "Build" stage run x86, x64 and arm64 together. "Test" stage will start when all build finished.
This PR break down the "Build" stage and "Test" stage into platform specific stages. For each platform, test will only depend on specific platform's build - Test_x86 will only depend on Build_x86, etc.
//////////////
A microsoft employee must use /azp run to validate using the pipelines below.
WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.
For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.