microsoft / windows-dev-center-vsts-extension

Visual Studio Team Services (VSTS) extension for performing continuous delivery to the Windows Dev Center store from your automated CI builds
Other
41 stars 16 forks source link

Store-publish task silently ignores "flightid" parameter and does a production release if "track: flight" parameter not provided #117

Open traberc opened 3 weeks ago

traberc commented 3 weeks ago

We are working on automating our Microsoft Store application releases and were testing a release to a flight. Although the "flightid" parameter was provided to the store-publish task, the track: flight parameter was inadvertently left off.

Instead of the publish task reporting the parameter mismatch and stopping for clarification, it silently ignored the flight id and did a production release. This led to a global production release of a dev branch of the application.

It is our belief that the task should fail if a flight id or name is provided, but the track parameter is missing or not set to flight.

Here is the task output with no indication that the flight id parameter was ignored and a production release is occurring:

==============================================================================
Task         : Windows Store - Publish V3 Dev
Description  : Publish your app to the Windows Store
Version      : 3.0.23
Author       : Microsoft Corporation
Help         : Visit our GitHub repository for help on usage for [this task](https://github.com/Microsoft/windows-dev-center-vsts-extension/blob/master/docs/usage.md##windows-store---publish)
==============================================================================
Loading dependencies
Loading task inputs
Setting Store Broker environment
Start publishing
2024-09-16 22:14:38 : VssAdministrator : Telemetry is currently enabled.  It can be disabled by setting "$global:SBDisableTelemetry = $true". Refer to USAGE.md#telemetry for more information.  Stop seeing this message in the future by setting "$global:SBSuppressTelemetryReminder=$true"
2024-09-16 22:14:43 : VssAdministrator : The server has indicated that the result is not yet ready (received status code of [202]).  Will retry in [30] seconds.
2024-09-16 22:15:29 : VssAdministrator : Successfully cloned the existing submission and modified its content.
You can view it on the Dev Portal here:
    https://partner.microsoft.com/en-us/dashboard/products/xxxxx/submissions/xxxxx/
2024-09-16 22:15:32 : VssAdministrator : Package [xxxxx] current state is [InProcessing].  Waiting 180 seconds before checking again.
2024-09-16 22:18:46 : VssAdministrator : The submission has been successfully submitted.
This is just the beginning though.
It still has multiple phases of validation to get through, and there's no telling how long that might take.
You can view the progress of the submission validation on the Dev Portal here:
    https://partner.microsoft.com/en-us/dashboard/products/xxxxx/submissions/xxxxx/
or by running this command:
    Get-Submission -ProductId xxxxx -SubmissionId xxxxx
You can automatically monitor this submission with this command:
    Start-SubmissionMonitor -ProductId xxxxx -SubmissionId xxxxx -EmailNotifyTo VssAdministrator
Submitted submission xxxxx
The release won't be modified to store the submission ID.
Submission has been submitted. Skipping polling as requested.
You can view the progress of the submission validation on the Dev Portal here:
https://partner.microsoft.com/en-us/dashboard/apps/xxxxx/submissions/xxxxx/
Future tasks can consume the variable WS_SubmissionId using this task's reference name
For more information on output variables, visit https://github.com/Microsoft/azure-pipelines-agent/blob/master/docs/preview/outputvariable.md
Attaching Store Broker log file D:\a\1\s\SBLog.txt. You can download it alongside the agent logs.
louis-wuitton commented 2 weeks ago

Hi @traberc, thank you for sharing this, and this is a good catch. Before switching to YAML, the flight ID would appear only if the track parameter is set to "flight" on the UI. But now since more pipelines are moving to YAML, the error you described are more likely to happen. I will add a fix to address this issue.