Skip to content

ci(windows): pin msstore CLI to v0.4.2 now that #162 is fixed #5388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
azchohfi wants to merge 1 commit into
base: main
Choose a base branch
from
+28 −15
Open

ci(windows): pin msstore CLI to v0.4.2 now that #162 is fixed #5388

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/windows-installer.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -447,7 +447,7 @@ jobs:
if: startsWith(github.ref, 'refs/tags/') && vars.AETHERSDR_STORE_PRODUCT_ID != ''
uses: microsoft/microsoft-store-apppublisher@cc9910a8d59f2eb55cbb83df0a3800cf3b5300e0
with:
version: v0.4.1
version: v0.4.2

@ten9876 ten9876 Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right split — the action stays pinned by SHA while only the CLI version it fetches moves. I confirmed the action's action.yml at cc9910a8 takes version as a free-form input (defaulting to latest), so an arbitrary newer tag is plausible; the actual resolution happens in the bundled dist/index.js, which I did not audit, so that last step is read rather than verified.

Blast radius if v0.4.2 ever failed to resolve: this step has no continue-on-error and runs after the softprops release step above, so the run would go red with the release assets already published. Pre-existing structure from #5345, not introduced here — naming it because this bump is the first thing to exercise the new value, and it will do so on a live v* tag with no CI lane ahead of it.


- name: Stage Microsoft Store submission (draft)
if: startsWith(github.ref, 'refs/tags/') && vars.AETHERSDR_STORE_PRODUCT_ID != ''
Expand Down
34 changes: 22 additions & 12 deletions docs/WINDOWS-STORE-MSIX.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -235,7 +235,7 @@ On a `v*` tag push the workflow:
1. Builds `AetherSDR.exe`, runs `windeployqt`, packages the MSIX, and creates
the `.msixupload` (existing steps).
2. The pinned `microsoft/microsoft-store-apppublisher` action puts the pinned
`msstore` CLI v0.4.1 on PATH and the workflow logs `msstore --version`.
`msstore` CLI v0.4.2 on PATH and the workflow logs `msstore --version`.
3. `msstore reconfigure` authenticates from the four GitHub secrets.
4. `packaging/windows/publish-store.ps1` finds the `.msixupload` and runs
`msstore publish <pkg>.msixupload -id <ProductId> --uploadTimeout 300
Expand All @@ -257,18 +257,28 @@ If the MSIX packaging step (which is `continue-on-error`) produced no
`.msixupload`, `publish-store.ps1` warns and exits 0 rather than turning an
otherwise-successful release red.

The upload timeout is deliberately explicit. `msstore` CLI v0.4.0 and v0.4.1
have a regression where omitting `--uploadTimeout` supplies a zero-second Azure
blob network timeout, producing the characteristic `Uploading Bundle to Azure
blob: 0%` failure and exit code `-1`
The upload timeout is deliberately explicit, and stays that way — but it is no
longer a bug workaround. `msstore` CLI v0.4.0 and v0.4.1 had a regression where
omitting `--uploadTimeout` supplied a zero-second Azure blob network timeout,
producing the characteristic `Uploading Bundle to Azure blob: 0%` failure and
exit code `-1`
([microsoft/msstore-cli#162](https://github.com/microsoft/msstore-cli/issues/162)).
The script uses the documented workaround of 300 seconds. It deliberately
leaves verbose logging disabled because Actions logs are public and expanded
authentication or upload diagnostics could expose derived credentials that
GitHub cannot mask by their registered secret values. The affected CLI is
pinned to prevent `latest` from silently changing publish behavior; advance
that pin only after validating a released version containing
[microsoft/msstore-cli#163](https://github.com/microsoft/msstore-cli/pull/163).
That is fixed by
[microsoft/msstore-cli#163](https://github.com/microsoft/msstore-cli/pull/163)
and released in v0.4.2, which the pin above now names, so omitting the option
would correctly yield the documented 100 s default.

@ten9876 ten9876 Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified all three claims in this sentence against the upstream repo at tag v0.4.2, so this reads accurately:

Worth noting for anyone re-reading this later: the fix's own source comment spells out the precondition — the option's arity is ExactlyOne, so an omitted option is served by the factory without reaching the CustomParser at all. That is what makes "omitting the option would correctly yield the documented 100 s default" true, and it would stop being true if the arity were ever relaxed. Nothing to change here.


300 seconds is kept because 100 s is genuinely too short for this package. The
CLI sets no `StorageTransferOptions`, so a `.msixupload` under 256 MiB is
uploaded as a **single PUT** and the network timeout has to cover the whole
transfer rather than an individual chunk. AetherSDR's upload is ~200 MB, which
at 100 s would demand a sustained ~2 MB/s for the entire request.

@ten9876 ten9876 Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both halves of this check out: AzureBlobManager.cs:40 at v0.4.2 calls blobClient.UploadAsync(fileStream, blobUploadOptions, ct) with no StorageTransferOptions, and line 28 applies the value as blobClientOptions.Retry.NetworkTimeout — so the timeout does cover the whole request. And "~200 MB" is accurate: AetherSDR-26.9.1.0-Windows-x64.msixupload on the v26.9.1 release is 197 MB.

One caveat for future readers rather than for this PR: the single-PUT property holds only while the package stays under the SDK's 256 MiB InitialTransferSize. Past that it chunks and the timeout becomes per-chunk, at which point 300 s is generous rather than necessary. Fine at 197 MB — just not a size-independent rule.


The workflow deliberately leaves verbose logging disabled because Actions logs
are public and expanded authentication or upload diagnostics could expose
derived credentials that GitHub cannot mask by their registered secret values.
The CLI stays pinned to prevent `latest` from silently changing publish
behavior.
Comment on lines +280 to +281

@ten9876 ten9876 Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sentence this replaces ended with an instruction aimed at the next maintainer, not just a statement about today:

advance that pin only after validating a released version containing microsoft/msstore-cli#163.

Retiring the #163-specific half is right. But "validate a release before advancing the pin" is a standing rule that this PR is itself a clean instance of, and it has gone from the doc along with it. Suggest keeping it in general form:

Suggested change
The CLI stays pinned to prevent `latest` from silently changing publish
behavior.
The CLI stays pinned to prevent `latest` from silently changing publish
behavior; validate a release before advancing the pin.

Non-blocking.


### One-time setup (maintainer, outside the repo)

Expand Down
7 changes: 5 additions & 2 deletions packaging/windows/publish-store.ps1
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,8 +39,11 @@

.PARAMETER UploadTimeoutSeconds
Network timeout, in seconds, for each Azure blob upload request. Defaults
to 300. This is always passed explicitly because msstore CLI v0.4.0 and
v0.4.1 incorrectly use zero when --uploadTimeout is omitted.
to 300. The CLI sets no StorageTransferOptions, so a .msixupload under
256 MiB is sent as a single PUT and this timeout has to cover the entire
transfer rather than one chunk. At ~200 MB the CLI's own 100 s default
would require a sustained ~2 MB/s for the whole upload, so this is passed
explicitly as a deliberate value.

.PARAMETER Commit
Send the submission straight to certification instead of staging a draft.
Expand Down