[release/v7.4] Add version in description and pass store task on failure.#26895
Conversation
There was a problem hiding this comment.
Pull request overview
Backport to release/v7.4 that updates the MSIX Store publish template to improve Store listing clarity (by adding version info to the app description) and to make Store publish steps non-blocking when the Store publish task fails.
Changes:
- Prepends
ReleaseTagversion information to the Store listing description inside the SBJSON payload. - Updates Store publish task conditions to use
variables['...']syntax. - Marks Store publish tasks with
continueOnError: trueso the job can proceed even if publishing fails.
| displayName: 'Publish StoreBroker Package (Preview)' | ||
| condition: and(ne('${{ parameters.skipMSIXPublish }}', 'true'), eq('$(PREVIEW)', 'true')) | ||
| condition: and(ne('${{ parameters.skipMSIXPublish }}', 'true'), eq(variables['PREVIEW'], 'true')) | ||
| continueOnError: true |
There was a problem hiding this comment.
Same concern as above: continueOnError: true on the Preview Store publish task deviates from the repo’s typical usage (diagnostics-only) and can hide an actual publish outage.
If tolerating failures is required, please document the rationale inline (and/or gate via a parameter) so future maintainers don’t assume Store publishing is optional.
| continueOnError: true |
|
|
||
| # Add PowerShell version to the top of the description | ||
| $description = $json.listings.'en-us'.baseListing.description | ||
| $version = "$(ReleaseTag)" |
There was a problem hiding this comment.
Minor maintainability: $version = "$(ReleaseTag)" duplicates $tagString which was already set from $(ReleaseTag) earlier in the same script. Reusing the existing $tagString (or deriving version from it once) reduces duplication and ensures the changelog link and description are always based on the exact same value.
| $version = "$(ReleaseTag)" | |
| $version = $tagString |
| displayName: 'Publish StoreBroker Package (Stable/LTS)' | ||
| condition: and(ne('${{ parameters.skipMSIXPublish }}', 'true'), or(eq('$(STABLE)', 'true'), eq('$(LTS)', 'true'))) | ||
| condition: and(ne('${{ parameters.skipMSIXPublish }}', 'true'), or(eq(variables['STABLE'], 'true'), eq(variables['LTS'], 'true'))) | ||
| continueOnError: true |
There was a problem hiding this comment.
continueOnError: true is typically only used in this repo for non-critical diagnostic steps (e.g., “Capture Downloaded Artifacts” in .pipelines/templates/linux-package-build.yml / packaging/windows/package.yml). Using it on the actual Store publish task risks masking a real publish failure and letting the stage complete without a clear signal.
Consider either (1) adding an explicit comment here explaining the known/expected failure mode that makes this safe, or (2) gating continueOnError behind a parameter so it’s only enabled when you intentionally want to tolerate Store publish failures, while keeping the default behavior strict.
…ure. (PowerShell#26895) Co-authored-by: Justin Chung <[email protected]>
|
Send me your email |
Backport of #26895 and #26920 to release/v7.4
Triggered by @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
Improves the v7.4 MSIX release pipeline by adding version information to app description and enabling error continuation in store publish tasks for better error handling and release visibility.
Customer Impact
Regression
REQUIRED: Check exactly one box.
This is not a regression.
Testing
Verified by running MSIX release pipeline on main branch. Changes to store publish tasks have been tested and confirmed to improve pipeline resilience and release note visibility without breaking existing functionality.
Risk
REQUIRED: Check exactly one box.
This modifies critical MSIX release pipeline steps. However, the changes have been tested in main and are localized to improving store publishing error handling and release note visibility. The variable syntax update aligns with best practices.