Automate Patch and Revision versions using Azure DevOps Variable Library#6462
Merged
Conversation
Add version automation to the Open (Foundation) repo, mirroring the pattern
from the Aggregator repo. Uses a separate '{MajorVersion}-Foundation-Versions'
Library to track PatchVersion and Revision across builds.
- Add WindowsAppSDK-VersionVariables.yml to load version vars from Library
- Add WindowsAppSDK-UpdateLibrary-Job.yml to bump versions after official builds
- Update Official/PR/Nightly pipelines to include version templates
- Update PackTransportPackage to use Library-based versioning for official builds
- Patch only bumps on official builds (not PR or Nightly)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
agniuks
approved these changes
May 8, 2026
agniuks
reviewed
May 8, 2026
agniuks
reviewed
May 8, 2026
agniuks
reviewed
May 8, 2026
Contributor
Author
|
/azp run |
|
Azure Pipelines failed to run 1 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
agniuks
self-requested a review
May 14, 2026 20:03
agniuks
approved these changes
May 14, 2026
Dreynor87
added a commit
that referenced
this pull request
May 29, 2026
…ary (#6462) (#6485) * Automate Patch and Revision versions using Azure DevOps Variable Library Add version automation to the Open (Foundation) repo, mirroring the pattern from the Aggregator repo. Uses a separate '{MajorVersion}-Foundation-Versions' Library to track PatchVersion and Revision across builds. - Add WindowsAppSDK-VersionVariables.yml to load version vars from Library - Add WindowsAppSDK-UpdateLibrary-Job.yml to bump versions after official builds - Update Official/PR/Nightly pipelines to include version templates - Update PackTransportPackage to use Library-based versioning for official builds - Patch only bumps on official builds (not PR or Nightly) * Remove the system.debug, since parameters.debug is empty * Change name of pipeline run * Respond to Agne 1 * Revert the change to depending on Publish --------- Co-authored-by: Chris Wall (WIN SDE) <chriwall@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com>
kythant
added a commit
that referenced
this pull request
Jun 8, 2026
Original conflict resolution dropped main's PackTransportPackage version
automation (SetVersion, DetermineComponentNugetPackageVersion, UpdateFoundationLibrary
stage, UpdateLibrary-Job). This commit ports them, with placement and variable
names adapted for monobuild:
Placement (per user):
- SetVersion + DetermineComponentNugetPackageVersion tasks: in -Steps.yml
(not -Stage.yml) because monobuild moved everything reusable into Steps.
- UpdateFoundationLibrary stage: in -Stage.yml, after Pack, gated on
parameters.RunUpdateLibraryJob.
Variable namespace mapping (main -> monobuild):
FoundationMinorVersionResolved -> MinorVersion (statically defined)
FoundationPatchVersionResolved -> WindowsAppRuntimePatchVersion
FoundationPreviewRevisionResolved -> PreviewRevision
FoundationExperimentalRevisionResolved-> ExperimentalRevision
FoundationLibraryName -> LibraryName (= WinAppSDK-{Major}-Versions)
Library-group variable names (Foundation-prefixed -> Aggregate-prefixed,
to match what monobuild's shared template reads from the group):
FoundationPatchVersion -> AggregatePatchVersion
FoundationPreviewRevision -> AggregatePreviewRevision
FoundationExperimentalRevision -> AggregateExperimentalRevision
Files:
PackTransportPackage-Stage.yml: pass 3 new params to Steps.yml; add
UpdateFoundationLibrary stage (depends on Pack, gated on RunUpdateLibraryJob).
PackTransportPackage-Steps.yml: add PrOrNightly + BuildType params; export
\ from SetVersion; add DetermineComponentNugetPackageVersion
(adapted); switch PackNuget args to \ / \.
UpdateLibrary-Job.yml: rewrite with adapted var names; target shared
WinAppSDK-{Major}-Versions Library (not main's new {Major}-Foundation-Versions).
Drop the FoundationMinorVersion update step (monobuild defines MinorVersion
statically, not via Library).
VersionVariables.yml: DELETE. Duplicates monobuild's shared
Build/WindowsAppSDK/AzurePipelinesTemplates/WindowsAppSDK-Versions.yml@WinAppSDK
which already loads the Library group and computes Revision.
Foundation-{PR,Nightly,Official,DevTest}.yml: pass PrOrNightly, BuildType,
RunUpdateLibraryJob to PackTransportPackage-Stage.yml@self. Only Official
enables RunUpdateLibraryJob and exposes BuildType as a queue-time parameter.
Caveats for review:
- The shared WinAppSDK-{Major}-Versions group is also consumed by the
Aggregator. If the Aggregator has its own UpdateLibrary job that bumps
Aggregate* counters, this will double-bump. Consider gating or moving to
a Foundation-specific group if conflict arises.
- DetermineComponentNugetPackageVersion now produces \
that may differ from \ only in some
IsOfficial+stable+tag cases. Monitor the first Foundation-Official run
after this lands.
kythant
added a commit
that referenced
this pull request
Jun 8, 2026
…onLibrary stage Companion to 9db54a4 (VersionVariables.yml deletion). 9db54a4's `git add` of the 7 modified files was aborted by an unrelated pathspec failure and this commit is what should have gone in with that deletion. Drops the previous over-conservative "kept monobuild" Pattern 4 resolution and ports main #6462 (PR #6462: Automate Patch+Revision via ADO Variable Library) into the monobuild's structure. Placement follows the monobuild convention: reusable Steps in -Steps.yml, stage-shape in -Stage.yml. Variable namespace mapping (main -> monobuild): FoundationMinorVersionResolved -> MinorVersion (statically defined) FoundationPatchVersionResolved -> WindowsAppRuntimePatchVersion FoundationPreviewRevisionResolved -> PreviewRevision FoundationExperimentalRevisionResolved-> ExperimentalRevision FoundationLibraryName -> LibraryName (= WinAppSDK-{Major}-Versions) Library-group variable name mapping (Foundation-prefixed -> Aggregate-prefixed, to match what monobuild's shared Versions.yml@WinAppSDK reads from the group): FoundationPatchVersion -> AggregatePatchVersion FoundationPreviewRevision -> AggregatePreviewRevision FoundationExperimentalRevision -> AggregateExperimentalRevision Files in this commit: PackTransportPackage-Stage.yml: pass 3 new params to Steps.yml; add UpdateFoundationLibrary stage (depends on Pack, gated on RunUpdateLibraryJob). PackTransportPackage-Steps.yml: add PrOrNightly + BuildType params; export packageVersion from SetVersion; add DetermineComponentNugetPackageVersion (adapted); switch PackNuget args to packageVersion + componentPackageVersion. UpdateLibrary-Job.yml: rewrite with adapted var names; target the shared WinAppSDK-{Major}-Versions Library (not main's new {Major}-Foundation-Versions group, which would require creating new ADO infrastructure). Drop the Update FoundationMinorVersion step (monobuild defines MinorVersion statically, not via Library). Foundation-{PR,Nightly,Official,DevTest}.yml: pass PrOrNightly, BuildType, RunUpdateLibraryJob to PackTransportPackage-Stage.yml@self. Only Official enables RunUpdateLibraryJob and exposes BuildType as queue-time UI param. Caveats for reviewer: - The shared WinAppSDK-{Major}-Versions group is also consumed by the Aggregator. If the Aggregator has its own UpdateLibrary job that bumps Aggregate* counters, this Foundation job will double-bump them. Validate on first Foundation-Official run; if conflict, gate one side or move Foundation to a separate group. - DetermineComponentNugetPackageVersion produces componentPackageVersion that may differ from WindowsAppSDKFormattedVersion only in some IsOfficial+stable+tag cases. Most Nightly/PR runs will compute the same value through both paths; the divergence shows up only on Official.
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.
Add version automation to the Open (Foundation) repo, mirroring the pattern from the Aggregator repo. Uses a separate '{MajorVersion}-Foundation-Versions' Library to track PatchVersion and Revision across builds.
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.