[release/v7.6] Create infrastructure to create two msixs and msixbundles for LTS and Stable#27069
Conversation
There was a problem hiding this comment.
Pull request overview
Backport of #27056 to release/v7.6, updating Windows packaging/pipeline infrastructure so MSIX/MSIXBundle generation and store submission can handle LTS and Stable in parallel and respect metadata.json packaging flags.
Changes:
- Adjust MSIX package naming inputs in
New-MSIXPackageto support LTS/Stable coexistence via filename conventions. - Update Windows packaging pipeline to optionally build an additional Stable MSIX when LTS is also built.
- Update MSIX bundle creation and store-publish flow to produce/upload multiple bundles and select the correct bundle for store packaging.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
tools/packaging/packaging.psm1 |
Updates MSIX package naming composition to align with new LTS/Stable parallel artifact strategy. |
.pipelines/templates/packaging/windows/package.yml |
Adds Stable packaging flag handling and triggers an additional Stable MSIX build when LTS+Stable are both requested. |
.pipelines/templates/package-create-msix.yml |
Creates separate bundles and updates artifact upload + store packaging to work with multiple bundles. |
Comments suppressed due to low confidence (2)
.pipelines/templates/package-create-msix.yml:265
- Bundle selection for store packaging only distinguishes LTS vs non-LTS. If both Stable and Preview bundles ever exist under $(BundleDir), a Preview submission could accidentally pick the Stable bundle (or multiple bundles). Since the job already computes $IsPreview/$IsStable, select explicitly based on channel (LTS vs Preview vs Stable) and validate you matched exactly one bundle (error if 0 or >1).
# Select the correct bundle based on channel
$bundleFiles = @(Get-ChildItem -Path '$(BundleDir)' -Filter '*.msixbundle')
Write-Verbose -Verbose "Available bundles: $($bundleFiles.Name -join ', ')"
if ($IsLTS) {
$bundleFile = $bundleFiles | Where-Object { $_.Name -match '-LTS-' }
} else {
# Catches Stable or Preview
$bundleFile = $bundleFiles | Where-Object { $_.Name -notmatch '-LTS-' }
}
.pipelines/templates/package-create-msix.yml:277
- $bundleFile can be an array if multiple bundles match the filter, but the script treats it like a single file (e.g., Copy-Item -Path $bundleFile.FullName and logging $bundleFile.Name). Add an explicit Count check and select a single item (or fail) to avoid copying/uploading multiple bundles into StoreBundleDir unintentionally.
if (-not $bundleFile) {
Write-Error "No matching bundle found for channel '$currentChannel'. Available bundles: $($bundleFiles.Name -join ', ')"
exit 1
}
# Copy the selected bundle to a dedicated directory for store packaging
$storeBundleDir = '$(Pipeline.Workspace)\releasePipeline\msix\store-bundle'
New-Item $storeBundleDir -Type Directory -Force > $null
Copy-Item -Path $bundleFile.FullName -Destination $storeBundleDir -Force -Verbose
Write-Host "##vso[task.setvariable variable=StoreBundleDir]$storeBundleDir"
Write-Verbose -Verbose "Selected bundle for store packaging: $($bundleFile.Name)"
| # Separate LTS and Stable/Preview MSIX files by filename convention | ||
| $ltsMsix = @(Get-ChildItem $sourceDir -Filter '*.msix' | Where-Object { $_.BaseName -match '-LTS-' }) | ||
| $stableMsix = @(Get-ChildItem $sourceDir -Filter '*.msix' | Where-Object { $_.BaseName -notmatch '-LTS-' }) | ||
|
|
||
| Write-Verbose -Verbose "Stable/Preview MSIX files: $($stableMsix.Name -join ', ')" |
There was a problem hiding this comment.
The bundling logic groups all non-LTS MSIX files together as “Stable/Preview” (anything not matching '-LTS-'). If both Stable and Preview MSIX artifacts are present in the same run, this will copy both into the same directory and attempt to create a single bundle that mixes different package identities, which makeappx bundling should reject (or worse, produce an invalid bundle). Consider splitting non-LTS into separate Stable vs Preview sets (e.g., match 'Preview'/'-preview' in the name) and either create separate bundles or fail fast when both are present.
This issue also appears in the following locations of the same file:
- line 256
- line 267
| @@ -175,6 +177,12 @@ jobs: | |||
|
|
|||
| Start-PSPackage -Type $packageTypes -SkipReleaseChecks -WindowsRuntime $WindowsRuntime -ReleaseTag $(ReleaseTagVar) -PackageBinPath $signedFilesPath -LTS:$LTS | |||
|
|
|||
| # When both LTS and Stable are requested, also build the Stable MSIX | |||
| if ($packageTypes -contains 'msix' -and $LTS -and $Stable) { | |||
| Write-Verbose -Verbose "Both LTS and Stable packages requested. Building additional Stable MSIX." | |||
| Start-PSPackage -Type msix -SkipReleaseChecks -WindowsRuntime $WindowsRuntime -ReleaseTag $(ReleaseTagVar) -PackageBinPath $signedFilesPath | |||
| } | |||
There was a problem hiding this comment.
$Stable is read from metadata.json, but it is only used to decide whether to do an additional Stable MSIX build when $LTS is also true. If metadata.StableRelease.Package can be false (the scenario described in the PR), this script still builds the non-LTS MSIX as part of the initial Start-PSPackage call whenever $packageTypes contains 'msix'. Consider gating the initial MSIX build on $Stable (e.g., remove 'msix' from $packageTypes when -not $Stable, or pass a flag so Start-PSPackage skips MSIX) so StableRelease.Package is actually respected.
…les for LTS and Stable (PowerShell#27069)
Backport of #27056 to release/v7.6
Triggered by @daxian-dbw on behalf of @jshigetomi
Original CL Label: CL-BuildPackaging
/cc @PowerShell/powershell-maintainers
Impact
REQUIRED: Choose either Tooling Impact or Customer Impact (or both). At least one checkbox must be selected.
Tooling Impact
Critical fix for MSIX and MSIX bundle packaging. The original implementation did not respect the package boolean in metadata.json, affecting Windows store publishing for v7.6.0 GA. This infrastructure update ensures both LTS and Stable MSIX bundles can be built in parallel with proper naming conventions and correct bundle selection during store publication.
Customer Impact
Regression
REQUIRED: Check exactly one box.
This is not a regression.
Testing
Verified through CI/CD pipelines. The changes ensure correct MSIX bundle creation and selection for both LTS and Stable channels, allowing both to coexist and be published appropriately. Tested packaging workflow validates proper bundle generation with -lts suffix for LTS packages.
Risk
REQUIRED: Check exactly one box.
High risk as this modifies core build infrastructure and MSIX packaging logic for both LTS and Stable channels. The changes affect how bundles are created, named, and published to the store. However, the fix is necessary to respect metadata.json configuration for the 7.6.0 GA release and ensure proper LTS/Stable package handling.