ci(store): submit the appx to the Microsoft Store from the release build - #311
Open
EtienneLescot wants to merge 2 commits into
Open
ci(store): submit the appx to the Microsoft Store from the release build#311EtienneLescot wants to merge 2 commits into
EtienneLescot wants to merge 2 commits into
Conversation
Uploading the Store package was the last manual step of a release, and it has already cost one blocked submission: 1.8.0 ended up with two different packages under a single version because the artifact was downloaded twice and both copies uploaded, which Partner Center rejects outright. The job runs on stable tags only. An RC reaching the Store would go through certification and land on every user's machine as an automatic update, so `!contains(tag, '-')` is what separates v1.9.1 from v1.9.1-rc.2. It lives in build.yml rather than beside publish-winget.yml because the appx never becomes a release asset — the GitHub release carries only the NSIS installer, so `release: published` has nothing to hand a downstream workflow. The package exists solely as this run's artifact. Gated on the credentials existing, like the macOS signing job: absent, it warns and skips, leaving the manual upload path intact; partially configured, it fails rather than silently shipping nothing while the release looks complete. `vars.MSSTORE_PRODUCT_ID` gates the job itself so a fork cannot publish to our listing. This removes the upload, not the certification: every submission still waits for Microsoft to validate it. Microsoft also restricts automated updates to free products, which OpenScreen is.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe release workflow adds conditional Microsoft Store publishing for stable releases. It validates credentials, submits one ChangesMicrosoft Store publishing
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant ReleaseArtifact
participant MicrosoftStoreCLI
participant PartnerCenter
GitHubActions->>ReleaseArtifact: Download the Windows .appx artifact
GitHubActions->>MicrosoftStoreCLI: Configure Store credentials
MicrosoftStoreCLI->>PartnerCenter: Submit the single .appx for the product
PartnerCenter-->>GitHubActions: Return submission status
GitHubActions->>GitHubActions: Write the execution summary
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build.yml:
- Around line 857-865: Update the Store publishing workflow by assigning an id
to the submission step, then revise the Summary step to use the resolver outcome
and submission step outcome rather than steps.store.outputs.enabled. Report
submission only when configuration resolves and publishing succeeds; otherwise
distinguish skipped publishing from a failed submission, including
partial-credential or CLI configuration failures.
In `@technical-documentation/engineering/release-and-secrets.md`:
- Line 91: Update the release documentation statement about the publish-msstore
job to specify that it runs for stable tag pushes and stable releases triggered
manually through workflow_dispatch, while retaining the explanation that RC
releases are excluded.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 001e2028-8b52-4d42-9de8-c6f5b3f51a82
📒 Files selected for processing (2)
.github/workflows/build.ymltechnical-documentation/engineering/release-and-secrets.md
The summary keyed off `enabled` alone under always(), so it claimed "Submitted to the Store" when `msstore publish` had failed, and "skipped, no credentials" when the resolver had rejected a half-configured one. A release summary asserting success over a package that never left the runner is the exact failure mode this job exists to remove. It now reads the resolver and submit step outcomes and distinguishes four states: submitted, skipped for want of credentials, half-configured, and submission failed. Values reach the script through env rather than expanding into shell source. Docs: the job also runs for a workflow_dispatch carrying a stable release_tag, not only for pushed tags.
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
1 participant
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.
Removes the last manual step of a release.
Why
Uploading the Store package was done by hand, and it has already cost one blocked submission: 1.8.0 ended up with two different packages under a single version because the artifact was downloaded twice and both copies uploaded. Partner Center rejects that outright — same full name, different content — and the submission sat stuck until one was deleted.
What it does
build.ymlgains apublish-msstorejob using Microsoft's own Store Developer CLI action:Stable tags only. An RC reaching the Store would go through certification and land on every user's machine as an automatic update, so
!contains(tag, '-')is what separatesv1.9.1fromv1.9.1-rc.2.Why in
build.ymland not next topublish-winget.ymlThe other publish workflows trigger on
release: publishedbecause they consume release assets. The appx never becomes one — the GitHub release carries only the NSIS installer. The package exists solely as this run's artifact, so the job has to live in the run that produces it.Gating
Same all-or-nothing idiom as the macOS signing job:
vars.MSSTORE_PRODUCT_IDgates the job itself, so a fork can never publish to our listing.Verified by extracting the real gate script out of
build.yml— including the secret names from its ownrequired=(...)array, so the test cannot drift:The submit step also refuses to guess: it fails if the artifact contains no
.appx, and fails if it contains more than one.What this does not remove
Certification. Every submission still waits for Microsoft to validate it; the update goes live afterwards. This removes the upload, not the wait.
Two constraints from Microsoft's docs, both satisfied here: automated updates are supported for free products only, and the app must already be published and live — the API cannot create a listing, only submit to an existing one.
Setup still required (one-time, and free)
Documented in
release-and-secrets.md. Worth noting that an Entra app registration needs no Azure subscription — that was the wall we hit on Azure Trusted Signing, and it does not apply here.The ordering matters: the Entra application must be added in Partner Center under User management → Microsoft Entra applications with the Manager role. Tenant and client IDs alone are not enough, and the failure is an authorization error at submit time rather than at configuration time.
Noted, not done
msstore submission updateMetadatacan drive the Store listing text from a versionedmetadata.json— which would replace the CSV export/fill/import round-trip entirely. Left out of this PR.Summary by CodeRabbit
New Features
Documentation