feat: add IsMonobuild parameter to step templates for self-ref support#6433
Merged
kythant merged 16 commits intorelease/dev/monobuildfrom Apr 28, 2026
Merged
Conversation
In the monobuild context, the WindowsAppSDK monorepo IS the self repo, so @WinAppSDK template references would require declaring a self-ref repository resource (which has compile-time-only ref limitations). Add an IsMonobuild parameter (default false) to all 7 step templates. When true, shared templates (PublishSymbol, DetermineVersion, EsrpCodeSigning, ConvertWttLogToXUnit) are invoked WITHOUT the @WinAppSDK suffix, resolving from self. Per-component pipelines work unchanged (default IsMonobuild=false preserves @WinAppSDK cross-repo behavior). The monobuild caller (Foundation-Build-Stage.yml) passes IsMonobuild=true.
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s), but failed to run 1 pipeline(s). |
When IsMonobuild=true, shared templates need to reference the running pipeline's self repo (the WinAppSDK monorepo). An un-suffixed template reference resolves relative to the calling template's repo (Foundation), not the pipeline's self. Use @self suffix to explicitly reference the running pipeline's repo, which is the WinAppSDK monorepo in the monobuild context.
In the per-component context, BuildAll.ps1 expects NuGetLicense files at WinAppSDK/Build/WindowsAppSDK/NuGetLicense (relative to repo root) because the WinAppSDK monorepo is checked out as a separate folder. In the monobuild context, the WinAppSDK monorepo IS the repo root, so the files live at Build/WindowsAppSDK/NuGetLicense. Add a conditional pre-step that mirrors them to the expected per-component path so BuildAll.ps1 finds them without needing modification.
Don't assume the NuGetLicense source path - try both s/Build/... and s/WinAppSDK/Build/... since OneBranch's checkout layout depends on which checkout it processes first. Print debug info if neither found.
Replace 10 inline if/else blocks across 7 step templates with a single template invocation per call site. Each shared template gets one wrapper: - WindowsAppSDK-EsrpCodeSigning-Wrapper.yml - WindowsAppSDK-PublishSymbol-Wrapper.yml - WindowsAppSDK-DetermineVersion-Wrapper.yml - WindowsAppSDK-ConvertWttLogToXUnit-Wrapper.yml Each wrapper accepts IsMonobuild + InnerParams (object) and dispatches to either @WinAppSDK or @self at compile time via if/else. Net: 65 lines removed, no behavior change.
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s), but failed to run 1 pipeline(s). |
Replaces the filesystem mirror approach with a direct REST API fetch from
the OS/WinAppSDK repo. This avoids needing a checkout step at all - no
WinAppSDK repo resource, no checkout: self with a path: directive (which
OneBranch silently ignores in dual-checkout scenarios).
Uses System.AccessToken for auth. Fetches preview/license.txt and
release/license.txt from refs/heads/release/dev/monobuild and places
them at the path BuildAll.ps1 expects:
WinAppSDK/Build/WindowsAppSDK/NuGetLicense/{preview,release}/license.txt
This reverts commit de240bf.
- Update Mirror script to copy NuGetLicense from \/Build/WindowsAppSDK/NuGetLicense (monobuild self) to \/WindowsAppSDK/WinAppSDK/Build/WindowsAppSDK/NuGetLicense (where BuildAll.ps1 expects, relative to Foundation) - Add workingDirectory: \/WindowsAppSDK to BuildAll.ps1 PowerShell tasks when IsMonobuild=true so they run from Foundation root - Other path references (\\BuildOutput, etc.) don't matter for the Pack portion - BuildAll.ps1 writes/reads relative to its working directory
This reverts commit 492d12c.
…path Diag dir output confirmed self (monobuild) lands at s/WinAppSDK and Foundation lands at s/. Foundation's BuildAll.ps1 hardcoded path 'WinAppSDK/Build/WindowsAppSDK/NuGetLicense/preview/license.txt' is relative to its own location (s/) and resolves to the monobuild's copy at s/WinAppSDK/Build/WindowsAppSDK/NuGetLicense/preview/license.txt. No mirror needed.
Diag dir output from build 145657939 confirmed the actual layout when PackFoundation runs both checkouts: - self (WinAppSDK monorepo): C:\__w\1\s\WinAppSDK\ - Foundation: C:\__w\1\s\WindowsAppSDK\ BuildAll.ps1 (in Foundation root) reads NuGetLicense via the relative path 'WinAppSDK\Build\WindowsAppSDK\NuGetLicense\...', which resolves against its own location. The previous attempts mirrored the wrong source (s\Build\... instead of s\WinAppSDK\Build\...) and the 'remove mirror' commit assumed Foundation was at s\ rather than s\WindowsAppSDK\. Re-add the mirror with correct paths and add workingDirectory to StageFiles + PackNuget so BuildAll.ps1 runs from Foundation root. Gated on IsMonobuild so per-component pipelines are unaffected.
PowerShell@2 resolves filePath relative to Build.SourcesDirectory before workingDirectory takes effect, so filePath BuildAll.ps1 fails in monobuild (BuildAll.ps1 is at s\WindowsAppSDK\, not s\). Same issue affects other Foundation-relative paths. Use $(Build.SourcesDirectory)\WindowsAppSDK as the Foundation root in monobuild for: StageFiles filePath, Copy-symbols sourceFolder, SetVersion nuspec path, PackNuget filePath, MoveToOutputDirectory FullNuget SourceFolder. Per-component pipeline behavior unchanged via the else branches.
This reverts commit 903e7cf.
In monobuild, BuildAll.ps1 lives at s/WindowsAppSDK/ and reads BuildOutput\ relative to its own location. Artifact downloads must therefore land at s/WindowsAppSDK/BuildOutput, not s/BuildOutput. Apply the same monobuild-aware conditioning to the 6 DownloadPipelineArtifact@2 calls (3 Foundation per-platform, 1 Foundation anycpu, 3 MRT per-platform). This is the missing piece from the previous monobuild Pack iteration: filePath/workingDirectory were corrected, but the downloaded artifacts still landed at the per-component path so StageFiles/PackNuget had nothing to stage and exit 1.
…tes-monobuild-aware Conflict in WindowsAppSDK-PackTransportPackage-Steps.yml: upstream PR #6434 folded the standalone Foundation anycpu DownloadPipelineArtifact into the per-platform loop and renamed ProjectReunion -> Project.Reunion in the push displayName; this branch had added monobuild-conditional targetPath to both. Resolution: keep upstream consolidated loop and displayName, drop the redundant standalone anycpu block, and preserve the conditional targetPath on the consolidated loop and on the MRT loop.
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s), but failed to run 1 pipeline(s). |
alexlamtest
reviewed
Apr 28, 2026
| # @WinAppSDK (per-component pipelines) or @self (monobuild) at compile time. | ||
|
|
||
| parameters: | ||
| - name: IsMonobuild |
Contributor
There was a problem hiding this comment.
Nit: unnecessary indentation? The 2 spaces are not required, I think. But that should be ok.
Similar below, not repeating.
alexlamtest
reviewed
Apr 28, 2026
| @@ -46,7 +54,10 @@ steps: | |||
| pipeline: $(_foundationBuildOutputPipeline) | |||
Contributor
There was a problem hiding this comment.
Nit: This indentation looks unusual in yml code. But it might just work.
alexlamtest
approved these changes
Apr 28, 2026
kythant
deleted the
user/kythant/foundation-step-templates-monobuild-aware
branch
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
2 participants
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.
In the monobuild context, the WindowsAppSDK monorepo IS the self repo, so @WinAppSDK template references would require declaring a self-ref repository resource (which has compile-time-only ref limitations).
Add an IsMonobuild parameter (default false) to all 7 step templates. When true, shared templates (PublishSymbol, DetermineVersion, EsrpCodeSigning, ConvertWttLogToXUnit) are invoked WITHOUT the @WinAppSDK suffix, resolving from self.
Per-component pipelines work unchanged (default IsMonobuild=false preserves @WinAppSDK cross-repo behavior). The monobuild caller (Foundation-Build-Stage.yml) passes IsMonobuild=true.
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.