Make staging self-update persistence E2E hermetic

[Mitch Denny (mitchdenny)]

Important

Superseded — not intended to merge. #19727 fixes #19708 with a tests-only change and is the preferred approach.

Follow-up experiment showed the production hook in this PR is not required to fix the bug. The restore failure is fully addressed by the existing packages install-sidecar field, which is pure test configuration. The ASPIRE_CLI_STAGING_DOWNLOAD_BASE_URL hook only additionally buys PR-gating of the identity reader path — not worth a permanent, security-sensitive redirect in shipping CliDownloader.cs.

Recommendation left on #19727: take that PR, but keep the project-update leg and make its restore hermetic via packages, so the original test intent (persisted channel landing in a project's aspire.config.json) isn't lost. See #19727 (comment).

Retained here as the record of the root-cause investigation and as the heavier hermetic alternative. Will close once #19727 lands.

---

Description

The failure in #19708 exposed two separate facts:

1. The live staging alias served 13.5.3+b5f14331, while the identity-derived darc-pub-microsoft-aspire-b5f14331 feed did not contain Aspire.AppHost.Sdk 13.5.3.
2. The E2E test replaced the current branch's CLI with that already-published binary, so no fix in the branch under test could affect the relaunched process.

The CLI's existing behavior is correct for its externalized identity: channel=staging, version=13.5.3, and commit=b5f14331 must resolve as that staging identity. This PR deliberately does not add physical-binary branching or change package provenance.

Instead, the test now serves a checksum-validated archive of the current-source CLI from a local loopback server. Its install sidecar supplies the complete test identity inputs: self-update persists channel=staging, preserves the explicit local package directory, and the relaunched current-source CLI performs the implicit project update. This keeps the scenario hermetic while continuing to exercise executable replacement, sidecar persistence, relaunch, package restore, and project channel persistence.

A dedicated ASPIRE_CLI_STAGING_DOWNLOAD_BASE_URL test hook enables the local archive source. It is staging-only, accepts only absolute loopback HTTP(S) URLs, bypasses proxies, rejects redirects, and revalidates the response URI. Production staging package routing is unchanged.

Validation:

• Reproduced the original failure against current main on the first Docker E2E run.
• Focused downloader, identity-routing, sidecar, and self-update tests: 24 passed.
• SelfUpdateToStaging_RelaunchedCliUsesStagingForImplicitProjectUpdate: 2 consecutive runs passed, followed by a final passing run, with quarantined and outerloop tests excluded.

Security considerations

The test hook controls executable acquisition, so it is intentionally constrained to direct loopback HTTP(S) connections. Proxy use and redirects are disabled, the final response URI is checked again, and the existing SHA-512 archive validation remains in place.

Fixes #19708

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

---

This fix was generated using the fix-flaky-test skill.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19731

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19731"

[Copilot]

Pull request overview

Separates persisted CLI update routing from physical build provenance so staging self-updates can correctly use stable packages.

Changes:

• Tracks effective and assembly build channels separately.
• Pins stable-stamped staging replacements to NuGet.org packages.
• Adds unit and self-update E2E coverage.

Show a summary per file

File	Description
src/Aspire.Cli/Acquisition/IIdentityResolver.cs	Adds build-channel resolution.
src/Aspire.Cli/Acquisition/IdentityResolver.cs	Resolves physical build identity separately.
src/Aspire.Cli/CliExecutionContext.cs	Stores route source and build channel.
src/Aspire.Cli/Program.cs	Propagates resolved channel identities.
src/Aspire.Cli/Packaging/PackageChannel.cs	Separates channel persistence from NuGet configuration.
src/Aspire.Cli/Packaging/PackagingService.cs	Selects staging package provenance and download URL.
tests/Aspire.Cli.Tests/Utils/TestExecutionContextHelper.cs	Supports distinct channel identities in tests.
tests/Aspire.Cli.Tests/Acquisition/IdentityResolverTests.cs	Verifies sidecar and build identities.
tests/Aspire.Cli.Tests/Packaging/PackagingServiceTests.cs	Tests staging provenance decisions.
tests/Aspire.Cli.Tests/Packaging/PackageChannelTests.cs	Tests NuGet.org-only staging behavior.
tests/Aspire.Cli.EndToEnd.Tests/SelfUpdateChannelPersistenceTests.cs	Exercises local self-update and relaunch.
docs/cli-staging-validation.md	Documents provenance and test overrides.

Review details

• Files reviewed: 12/12 changed files
• Comments generated: 1
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

tests/Aspire.Cli.Tests/Utils/CliDownloaderTests.cs:100

• This test can still pass if redirects are accidentally enabled: following this URL will usually fail or return a non-success status, producing the same HttpRequestException expected below. It also lets a regression make an external network request. Point the redirect at a second loopback listener that returns 200 and records requests, then assert that listener was never contacted; that makes the redirect-protection regression test hermetic and conclusive.

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/Aspire.Cli/Utils/CliDownloader.cs:57

• The redirect test does not exercise this wiring: it calls DownloadFileAsync(..., requireLoopback: true) directly, while the E2E server returns only 200 responses. If this condition were removed or accidentally evaluated to false, every new test would still pass and staging overrides would again use the proxy/redirect-enabled client. Add coverage through DownloadLatestCliAsync (or refactor URL resolution to return the restriction flag together with the URL) and have the configured staging endpoint return a redirect, so the security guarantee is tested at its entry point.

        var requireLoopback = string.Equals(channel.Name, PackageChannelNames.Staging, StringComparisons.ChannelName) &&
            environment.GetEnvironmentVariable(StagingDownloadBaseUrlEnvVar) is { Length: > 0 };

tests/Aspire.Cli.EndToEnd.Tests/SelfUpdateChannelPersistenceTests.cs:64

• Using a fixed port makes this E2E fail whenever 38417 is already bound in the test container; nohup can hide the bind failure until the readiness curl times out or contacts an unrelated listener. Have the Python server bind port 0 and communicate the selected port back to the shell before exporting the URL, as the Kestrel test below already does.

            "feed_root=/tmp/aspire-self-update-feed; port=38417; " +

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (1)

tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj:21

• This says the test uses an off-loopback redirect, but the redirect target is /redirected.tar.gz on the same loopback Kestrel server. The test proves that redirects are disabled; describe that actual coverage rather than a target it does not create.

  <!-- CliDownloaderTests hosts a real Kestrel endpoint to prove the loopback-only staging download
       hook rejects an off-loopback redirect instead of following it. -->

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (1)

tests/Aspire.Cli.EndToEnd.Tests/SelfUpdateChannelPersistenceTests.cs:15

• Keep this test quarantined after landing the fix. The repository policy explicitly says a fix PR must retain [QuarantinedTest] until the test has zero failures across all operating systems for 21 consecutive days (docs/unquarantine-policy.md:5-22). Three successful runs do not meet that gate, so removing the attribute immediately bypasses the reliability observation period.

    public async Task SelfUpdateToStaging_RelaunchedCliUsesStagingForImplicitProjectUpdate()

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Tests selector (audit mode)

The full test matrix and all jobs still run in audit mode. The tests and jobs below are what selective CI would run under enforcement.

2 / 102 test projects · 4 jobs, from 4 changed files.

Selected test projects (2 / 102)

Aspire.Cli.EndToEnd.Tests, Aspire.Cli.Tests

Selected jobs (4)

deployment-e2e, extension-e2e, polyglot, typescript-api-compat

---

How these were chosen — grouped by what changed

📦 affected project Aspire.Cli
→ 1 test: Aspire.Cli.EndToEnd.Tests

🧪 tests/Aspire.Cli.EndToEnd.Tests/SelfUpdateChannelPersistenceTests.cs (changed test)
→ 1 directly: Aspire.Cli.EndToEnd.Tests

🧪 tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/Utils/CliDownloaderTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

Job reasons

Job	Triggered by
deployment-e2e	affected project Aspire.Cli
extension-e2e	• src/Aspire.Cli/Utils/CliDownloader.cs, tests/Aspire.Cli.EndToEnd.Tests/SelfUpdateChannelPersistenceTests.cs, tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj, tests/Aspire.Cli.Tests/Utils/CliDownloaderTests.cs • affected project Aspire.Cli
polyglot	affected project Aspire.Cli
typescript-api-compat	affected project Aspire.Cli

---

Selection computed for commit 3315f44.

[Copilot]

Review details

Suppressed comments (1)

tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj:21

• This comment says the test uses an off-loopback redirect, but the redirect target is the relative /redirected.tar.gz route on the same loopback Kestrel server. The test proves that all redirects are rejected, so describe that behavior rather than an off-loopback redirect.

  <!-- CliDownloaderTests hosts a real Kestrel endpoint to prove the loopback-only staging download
       hook rejects an off-loopback redirect instead of following it. -->

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced