Description
#20136 reports that installing/updating the stable Aspire CLI through winget downloads from a preview-tagged ci.dot.net path even though winget reports a stable version number:
Found Aspire CLI [Microsoft.Aspire] Version 13.5.3
Downloading https://ci.dot.net/public/aspire/13.5.3-preview.1.26425.3/aspire-cli-win-x64-13.5.3.zip
PR #20168 fixes the equivalent problem for the get-aspire-cli.sh / get-aspire-cli.ps1 script installers (they now resolve the latest stable version via GitHub's release redirect and download from github.com/.../releases/download/... instead of the aka.ms channel). It does not fix the winget manifest, for a structural reason in the release pipeline, not just build-vs-release timing:
Stage: Release
└─ WinGetJob (dependsOn: ReleaseJob) ← generates + submits the WinGet manifest PR here
Stage: GitHubTasks (dependsOn: [Release, PrepareArtifacts])
└─ DispatchGitHubTasksJob ← creates the git tag + DRAFT GitHub Release
└─ PublishReleaseAssetsJob ← uploads aspire-cli-*.zip/tar.gz to the draft
(eng/pipelines/release-publish-nuget.yml.) WinGetJob submits the manifest to microsoft/winget-pkgs in the Release stage, entirely before the GitHubTasks stage runs — the GitHub tag/release/assets don't exist yet at that point in the pipeline, regardless of any script-level fix.
It's also not just an ordering problem: the GitHub release is created as a draft, and per the pipeline's own comments, draft-release assets are not publicly downloadable until a human (the release manager) manually publishes the draft as a final, unscheduled step (docs/release-process.md, "Publish the draft release"). eng/pipelines/templates/publish-winget.yml does a live HTTP HEAD reachability check on every InstallerUrl before submitting the manifest — pointing it at a GitHub release URL would fail that check on every real stable release until the draft is published, which today happens well after WinGetJob runs.
So a real fix needs more than reordering: it needs winget manifest submission to either wait on the manual "publish draft" step, or move to a separate post-publish trigger (comparable to how Homebrew's cask bump is validated by .github/workflows/homebrew-validate-release.yml on the release: [published] event, after the release manager publishes).
Expected behavior
The winget manifest for a stable Aspire CLI release should ultimately point at (or otherwise avoid exposing) a preview-tagged storage path, consistent with what winget show/winget upgrade reports as the package version.
Suggested next steps
- Investigate restructuring
WinGetJob to run only after the GitHub release is published (not just created as a draft) — e.g. moving winget submission to a separate stage/workflow gated on release: [published], mirroring the Homebrew autobump/validate flow.
- Alternatively, investigate whether the CI artifact naming itself can avoid embedding a
-preview.* segment in the path used for what will become the stable release, independent of the winget/script consumption path.
- Either approach needs to account for the release manager's manual "publish draft" step not being scheduled/guaranteed to happen promptly — a design that blocks indefinitely on that step could stall in-flight winget submissions.
Description
#20136 reports that installing/updating the stable Aspire CLI through winget downloads from a preview-tagged
ci.dot.netpath even though winget reports a stable version number:PR #20168 fixes the equivalent problem for the
get-aspire-cli.sh/get-aspire-cli.ps1script installers (they now resolve the latest stable version via GitHub's release redirect and download fromgithub.com/.../releases/download/...instead of the aka.ms channel). It does not fix the winget manifest, for a structural reason in the release pipeline, not just build-vs-release timing:(
eng/pipelines/release-publish-nuget.yml.)WinGetJobsubmits the manifest tomicrosoft/winget-pkgsin theReleasestage, entirely before theGitHubTasksstage runs — the GitHub tag/release/assets don't exist yet at that point in the pipeline, regardless of any script-level fix.It's also not just an ordering problem: the GitHub release is created as a draft, and per the pipeline's own comments, draft-release assets are not publicly downloadable until a human (the release manager) manually publishes the draft as a final, unscheduled step (
docs/release-process.md, "Publish the draft release").eng/pipelines/templates/publish-winget.ymldoes a live HTTP HEAD reachability check on everyInstallerUrlbefore submitting the manifest — pointing it at a GitHub release URL would fail that check on every real stable release until the draft is published, which today happens well afterWinGetJobruns.So a real fix needs more than reordering: it needs winget manifest submission to either wait on the manual "publish draft" step, or move to a separate post-publish trigger (comparable to how Homebrew's cask bump is validated by
.github/workflows/homebrew-validate-release.ymlon therelease: [published]event, after the release manager publishes).Expected behavior
The winget manifest for a stable Aspire CLI release should ultimately point at (or otherwise avoid exposing) a preview-tagged storage path, consistent with what
winget show/winget upgradereports as the package version.Suggested next steps
WinGetJobto run only after the GitHub release is published (not just created as a draft) — e.g. moving winget submission to a separate stage/workflow gated onrelease: [published], mirroring the Homebrew autobump/validate flow.-preview.*segment in the path used for what will become the stable release, independent of the winget/script consumption path.