Merged
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14557Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 14557" |
Contributor
There was a problem hiding this comment.
Pull request overview
Enables Aspire’s container tunnel by default to provide consistent container-to-host connectivity across orchestrators, while updating OTLP/dashboard endpoint modeling and refactoring DCP startup work for better parallelism and correctness.
Changes:
- Default-enable the container tunnel and refactor DCP object creation into finer-grained parallel tasks.
- Add a multi-resource dependency computation API and use it to determine tunnel-dependent resources.
- Update OTLP/dashboard endpoint naming and add/adjust tests (including a helper to reduce port-collision flakiness).
Reviewed changes
Copilot reviewed 20 out of 20 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| tools/perf/Measure-StartupPerformance.ps1 | Updates perf script launch profile handling and output behavior. |
| tests/Aspire.Hosting.Tests/ResourceDependencyTests.cs | Adds coverage for new multi-resource dependency resolution behavior. |
| tests/Aspire.Hosting.Tests/Helpers/Network.cs | Adds helper for selecting an available TCP port to reduce test flakiness. |
| tests/Aspire.Hosting.Tests/DistributedApplicationTests.cs | Uses dynamic ports in proxyless endpoint/container tests. |
| tests/Aspire.Hosting.Tests/Dashboard/DashboardResourceTests.cs | Switches OTLP endpoint name usage to centralized constants. |
| tests/Aspire.Hosting.Tests/Dashboard/DashboardLifecycleHookTests.cs | Switches OTLP endpoint name usage to centralized constants. |
| tests/Aspire.Hosting.Tests/ContainerTunnelTests.cs | Adds tunnel coverage for proxyless endpoints and adjusts YARP test behavior/timeouts. |
| tests/Aspire.Hosting.Tests/Aspire.Hosting.Tests.csproj | Adds Polly.Core dependency for new test helper. |
| src/Shared/OtlpEndpointResolver.cs | Extends OTLP resolution logic and adds helper to resolve scheme/port. |
| src/Shared/KnownEndpointNames.cs | Introduces shared OTLP endpoint-name constants. |
| src/Aspire.Hosting/OtlpConfigurationExtensions.cs | Centralizes OTLP env var key and uses resolver directly for endpoint/protocol. |
| src/Aspire.Hosting/Dcp/OtlpEndpointReferenceGatherer.cs | Adds DCP gatherer to replace OTLP endpoint env var with dashboard endpoint reference for containers. |
| src/Aspire.Hosting/Dcp/DcpOptions.cs | Enables container tunnel by default. |
| src/Aspire.Hosting/Dcp/DcpExecutor.cs | Refactors startup into interdependent tasks; adds tunnel-dependent container classification and OTLP gatherer hookup. |
| src/Aspire.Hosting/Dashboard/DashboardEventHandlers.cs | Uses shared OTLP endpoint-name constants and ensures endpoints are annotated. |
| src/Aspire.Hosting/AspireEventSource.cs | Adds events for service-object preparation timing. |
| src/Aspire.Hosting/Aspire.Hosting.csproj | Links new shared KnownEndpointNames into hosting assembly. |
| src/Aspire.Hosting/ApplicationModel/ResourceExtensions.cs | Adds efficient multi-resource dependency computation API and exposes direct-dependency gatherer internally. |
| src/Aspire.Hosting.Maui/Aspire.Hosting.Maui.csproj | Links shared KnownResourceNames/KnownEndpointNames into MAUI package. |
| playground/yarp/Yarp.AppHost/Properties/launchSettings.json | Removes explicit tunnel enablement since it’s now default. |
Comments suppressed due to low confidence (3)
src/Shared/KnownEndpointNames.cs:9
- These endpoint name fields are mutable static strings. They should be
const(or at leaststatic readonly) to prevent accidental mutation and to satisfy analyzers that flag non-constant static fields.
internal static class KnownEndpointNames
{
public static string OtlpGrpcEndpointName = "otlp-grpc";
public static string OtlpHttpEndpointName = "otlp-http";
src/Aspire.Hosting/Dcp/DcpExecutor.cs:3012
- Typo in exception message: 'follwing' should be 'following'.
var containerNames = persistentTunnelDependent.Select(td => td.ModelResource.Name).Aggregate(string.Empty, (acc, next) => acc + " '" + next + "'");
throw new InvalidOperationException($"The follwing containers are marked as persistent and rely on resources on the host network:{containerNames}. This is not supported.");
}
tests/Aspire.Hosting.Tests/ResourceDependencyTests.cs:779
- There is a stray extra semicolon here (
...WithHttpEndpoint(...); ;) which results in an empty statement. Please remove it to keep the test code clean.
// A -> B -> C -> A (circular), plus D as external dependency
var d = builder.AddContainer("d", "alpine")
.WithHttpEndpoint(8083, 8083, "http"); ;
var a = builder.AddContainer("a", "alpine")
Contributor
🎬 CLI E2E Test RecordingsThe following terminal recordings are available for commit
📹 Recordings uploaded automatically from CI run #22375825749 |
... to distinguish between "regular" and "tunnel" services
4cc4a4d to
6c74b5c
Compare
eerhardt
reviewed
Feb 23, 2026
danegsta
reviewed
Feb 23, 2026
danegsta
approved these changes
Feb 23, 2026
eerhardt
approved these changes
Feb 24, 2026
16 tasks
1 task
radical
added a commit
that referenced
this pull request
Mar 6, 2026
The merge conflict on DcpExecutor.cs was resolved by taking release/13.2's version, which discarded PR #14557's parallel, tunnel-aware container creation. However, DcpOptions.cs had no conflict, so #14557's EnableAspireContainerTunnel = true default was auto-preserved. The old DcpExecutor unconditionally blocks ALL container creation behind tunnel initialization (10-minute timeout), causing polyglot tests to time out waiting for Redis. The new DcpExecutor from #14557 intelligently parallelizes tunnel-dependent vs independent containers, but that code was lost in the merge. Reverting to false makes DcpOptions consistent with the DcpExecutor code taken from release/13.2. After the backmerge lands, main already has both the correct = true default AND the matching DcpExecutor from #14557. 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
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.
This PR enables Aspire container tunnel feature by default. This allows containers to consume resources on the host network. Without the tunnel (current default) it only works with Docker Desktop, because other container orchestrators lack the necessary bridging functionality.
To make it happen I made several changes and bug fixes to app model APIs,
DcpExecutor, and tests. Most importantly:ASPIRE_ENABLE_CONTAINER_TUNNEL#12998DistributedApplicationTeststo use it--it should help us get those out of quarantined status.CAVEAT: with this change, containers that use host resources will commence their startup after a delay (measured on my devbox VM as roughly 3-4 seconds in "warm" case). An example of such container is our Yarp integration, which pushes OTEL telemetry to the dashboard. This is because some of the endpoints they use are now provided by the tunnel, specifically the tunnel proxy container, that needs to start up and allocate these endpoints. Previously these contaienrs were leveraging Docker Desktop host connectivity, which required only textual replacement of the endpoint address
localhost-->host.docker.internal. This drawback has to be weighted against the fact that the tunnel provides uniform behavior regardless of the container orchestrator and that we need to get more feedback about it from the users, which we won't get if the tunnel remains off by default.Making the tunnel as fast as Docker Desktop-based solution is possible, but the plan for that requires making the tunnel itself persistent, which in turn requires persistent Executables, which is tracked here: microsoft/dcp#13