Clarify Aspire update channel resolution#17561
Draft
danegsta wants to merge 6 commits into
Draft
Conversation
Treat missing project channel configuration as the stable/default channel for existing app hosts, while preserving explicit PR dogfood defaulting with visible CLI output and an opt-out setting. Share channel update step formatting across .NET and polyglot update flows so channel changes are presented consistently before confirmation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17561Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17561" |
Use the shared channel persistence rule when scaffolding projects so stable remains represented by an absent channel while non-stable explicit channels are still pinned. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add a regression test that PR dogfood identity does not change the prompt-based channel selection behavior for aspire update --self. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
❓ CLI E2E Tests unknown — 34 passed, 0 failed, 50 unknown (commit View all recordings
📹 Recordings uploaded automatically from CI run #26540139192 |
The new channel-resolution model treats an explicit '--channel stable' against a project pinned to a non-stable channel as a request to change the project's pinned channel. The preview now surfaces an 'aspire.config.json#channel' change step alongside any package updates. Update ChannelUpdateWorkflowTests to assert that the preview includes the channel-change line (flipping the previous regression-guard assertion), and refresh class-level documentation and the deep TypeScript test's step comments to describe the new invariant. Declining the preview still leaves the on-disk channel value unchanged, so the existing preservation checks remain valid. Drop the stale 'aspire update --self saves the channel to global settings' description and the 'simulating what update --self does' Step 5 comment from StagingChannelTests — the test exercises only 'aspire config set' and the self-update path no longer writes channel to global config. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Commit 85d9591 stopped scaffolding from stamping 'stable' into aspire.config.json#channel (the new model treats absent as stable). NewCommand_NoChannelArg_ResolvesTemplateFromIdentityChannel was still asserting the old behavior where TemplateInputs.Channel was always set to the identity channel name, so the stable inline-data case began failing in CI with 'Expected stable, Actual null'. Add a third theory parameter for the expected persisted channel value (null for stable, identity for non-stable) and document why in a remarks block. The daily inline-data case continues to assert the identity is passed through. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.
Description
This change makes
aspire updatechannel resolution easier to reason about for existing AppHosts. Missing project/global channel config now consistently means the stable/default channel, while PR dogfood CLIs still get a visible convenience default to their concretepr-Nchannel when no channel is configured.The update flow now:
--channeland configured project/global channels before any dogfood behavior--channel pras an alias for the current PR dogfood CLI's concrete channelBehavior changes
aspire updatefrom a daily CLIdaily.aspire updatefrom a staging CLI--channel staging.aspire updatefrom a PR dogfood CLI with matchingpr-Nchannelpr-Nchannel, but prints an explicit notice and can be disabled withupdate.prDogfoodDefaultChannelEnabled=false.aspire updatewith hives present but no applicable PR dogfood default--channelto intentionally move to a hive or other channel."channel": "daily"aspire update --channel stableaspire.config.json#channel daily to stable, clears the persisted channel if accepted, and restore/regeneration use the selected stable/default channel.aspire update --channel prfrom a PR dogfood CLIpr-Nchannel.User-facing usage
Existing projects without
aspire.config.json#channelresolve as stable/default unless a PR dogfood CLI default applies:PR dogfood CLI users can explicitly target the current PR channel:
Users can disable the PR dogfood default with:
When a channel pin changes, both .NET and polyglot AppHosts show an explicit update step before confirmation, for example:
Validation:
dotnet build /t:UpdateXlf src/Aspire.Cli/Aspire.Cli.csproj --no-restore --verbosity minimaldotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj --no-launch-profile -- --filter-class "*.UpdateCommandTests" --filter-class "*.GuestAppHostProjectTests" --filter-class "*.ProjectUpdaterTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true"dailyto stable.Fixes # (issue)
Checklist
<remarks />and<code />elements on your triple slash comments?