fix(cli): use matching PR packages for PR-acquired aspire new#17280
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17280Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17280" |
b6666fa to
8f89514
Compare
A PR-acquired CLI installed under a custom dogfood prefix did not materialize its matching local package hive unless that hive also lived under the default Aspire home. Empty AppHost creation could then resolve Aspire packages from the normal channels or from a stale same-named hive, which breaks the version/source coherence expected for PR dogfood builds. Discover the co-installed package hive from the running PR CLI layout and prefer it over a same-named default hive. Invalid, missing, mismatched, or non-PR layouts fall back to the existing channel list instead of failing. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Cover the real new-command path for empty AppHost creation with a PR-acquired CLI layout. The matrix verifies that C# uses the PR hive for template generation and NuGet.config, while guest languages persist the matching PR channel and SDK version before prebuilt AppHost preparation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
PR-acquired CLI installs place their matching package hive under the install prefix, outside the default Aspire hives directory. Dotnet-backed `aspire new` templates still used the default hive count as the only local build signal, so they could ignore the co-installed PR hive and resolve from the implicit channel instead. Treat a discovered explicit local-build channel as a hive signal when resolving template packages. Expand the PR dogfood regression coverage to account for every registered `aspire new` template, with an explicit exclusion for the interactive `aspire-test` wrapper. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The template package resolver should not treat every registered `pr-*` channel as an installed hive. That made the hive-gate test select the PR channel even when no local hive/source existed on disk. Keep the dogfood install-prefix behavior, but only count a local-build channel as a hive signal when its Aspire package source is a local path that exists. Arbitrary registered channels without installed packages keep falling back to the implicit channel. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ac646ff to
aa600cf
Compare
PR Testing ReportPR Information
CLI Version Verification
Changes AnalyzedFiles Changed
Change Categories
Test Scenarios ExecutedScenario 1: Version verificationObjective: Install the PR CLI and verify Steps:
Evidence:
Observations: Scenario 2: C# empty AppHost without sourceObjective: Verify no-explicit-source C# template creation uses the matching PR hive. Steps:
Evidence:
Observations: Scenario 3: TypeScript empty AppHost without sourceObjective: Verify TypeScript template creation succeeds without the AtsJsonCodeWriter mismatch and pins pr-17280. Steps:
Evidence:
Observations: Scenario 4: Starter template without sourceObjective: Verify aspire-starter scaffolds from the discovered PR hive without explicit source/version. Steps:
Evidence:
Observations: Scenario 5: Stale default hive precedenceObjective: Verify an isolated stale default hive does not override the install-prefix hive. Steps:
Evidence:
Observations: Summary
Overall Result✅ PR VERIFIED RecommendationsNo issues found in the approved no-explicit-source scenarios. Artifacts
Cleanup StatusScenario/install workspace cleanup attempted after report generation. Logs and report retained in |
There was a problem hiding this comment.
Pull request overview
This PR fixes a dogfood/PR acquisition coherence issue in the Aspire CLI so that when the running CLI identity is pr-<N> and the CLI was installed via the PR “dogfood install prefix” layout, aspire new implicitly uses the matching co-installed PR package hive (without requiring --source). This prevents mixing PR CLI binaries with non-matching template/runtime/codegen packages from normal feeds.
Changes:
- Extend channel discovery to detect a
pr-<N>hive located beside a PR-installed CLI binary (dogfood install prefix layout) and prefer it over a same-named stale default hive. - Treat a discovered installed local-build package source as a “hive signal” during template package resolution when PR hives are included.
- Add targeted unit/integration tests covering the PR-dogfood hive discovery and ensuring
aspire newtemplates scaffold using the discovered PR channel/source.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tests/Aspire.Cli.Tests/Packaging/PackagingServiceTests.cs | Adds tests for discovering/prioritizing the PR dogfood install-prefix hive and edge cases (missing/mismatched/malformed). |
| tests/Aspire.Cli.Tests/Commands/NewCommandTemplateConfigPersistenceTests.cs | Adds scenario-level regression coverage to ensure registered aspire new templates use the discovered PR channel/source during scaffolding. |
| src/Aspire.Cli/Templating/TemplateNuGetConfigService.cs | Expands “has PR hives” detection to include discovered local-build sources so template resolution considers the appropriate channels. |
| src/Aspire.Cli/Packaging/PackagingService.cs | Implements PR dogfood install-prefix hive discovery based on the running process path, and prefers that hive over same-named default hives. |
Centralize the NuGet.org v3 index URL used by CLI package source mapping paths so channel construction and source override handling do not each carry their own literal. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Description
A PR-acquired Aspire CLI should scaffold
aspire newprojects from the matching PR packages without requiring users to pass--source. This affects dogfood flows such as:Before this change, those scenarios could mix the PR CLI/runtime/codegen assemblies with packages from normal configured sources. The observed TypeScript empty AppHost failure was:
The root cause was that channel discovery only looked under the default Aspire hives directory. A CLI installed with
get-aspire-cli-prcan run from a dogfood install prefix where the matchingpr-<N>package hive lives beside the installed CLI, so implicit template/restore paths could miss that source.This change discovers the matching co-installed PR hive for
pr-<N>CLI identities when the running CLI path matches the PR dogfood archive layout. That discovered hive is added as the PR channel and preferred over a same-named stale default hive, soaspire newuses the package source that matches the running PR CLI.The scenario-level behavior changes are:
apphost.csandnuget.configfrom the matching PR hive.pr-<N>channel for SDK restore/codegen.aspire newtemplates, including starter/service-defaults templates, install and scaffold from the discovered PR hive when no explicit source or channel is supplied.--source, explicit/configured channels, and malformed or mismatched install layouts keep the existing behavior.Fixes #17225
Checklist
<remarks />and<code />elements on your triple slash comments?