Add container runtime health check as orphan pipeline step#16196
Merged
Add container runtime health check as orphan pipeline step#16196
Conversation
davidfowl
requested review from
JamesNK,
danegsta,
karolz-ms and
mitchdenny
as code owners
davidfowl
force-pushed
the
davidfowl/deploy-delight
branch
from
6879cbc to
95ea21b
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds a dedicated pipeline step to validate the container runtime (Docker/Podman) health so deployments fail with a clearer root cause when the runtime is stopped, and allows interactive retry.
Changes:
- Introduce a new well-known pipeline step
check-container-runtime. - Register the step in
DistributedApplicationPipelinewith interactive prompting and non-interactive fail-fast behavior. - Make container/project build steps depend on the new health-check step; update pipeline tests accordingly.
Show a summary per file
| File | Description |
|---|---|
| tests/Aspire.Hosting.Tests/Pipelines/DistributedApplicationPipelineTests.cs | Updates expectations/targeting to account for the new default step. |
| src/Aspire.Hosting/Pipelines/WellKnownPipelineSteps.cs | Adds CheckContainerRuntime constant for cross-resource dependencies. |
| src/Aspire.Hosting/Pipelines/DistributedApplicationPipeline.cs | Registers the container runtime health-check step and its behavior. |
| src/Aspire.Hosting/ContainerResourceBuilderExtensions.cs | Adds dependency from container build step to the runtime check. |
| src/Aspire.Hosting/ApplicationModel/ProjectResource.cs | Adds dependency from project image build step to the runtime check. |
Copilot's findings
- Files reviewed: 5/5 changed files
- Comments generated: 4
JamesNK
approved these changes
Apr 15, 2026
Member
JamesNK
left a comment
JamesNK
left a comment
There was a problem hiding this comment.
Looks good — clean design with the orphan step pattern. One minor test gap noted.
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 16196Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 16196" |
davidfowl
force-pushed
the
davidfowl/deploy-delight
branch
from
8261d11 to
5cd3ac2
Compare
karolz-ms
approved these changes
Apr 15, 2026
eerhardt
reviewed
Apr 15, 2026
davidfowl
force-pushed
the
davidfowl/deploy-delight
branch
from
937c19e to
c46bd5f
Compare
eerhardt
reviewed
Apr 16, 2026
eerhardt
approved these changes
Apr 16, 2026
davidfowl
force-pushed
the
davidfowl/deploy-delight
branch
from
82db378 to
9ad3ab2
Compare
davidfowl
force-pushed
the
davidfowl/deploy-delight
branch
7 times, most recently
from
2f3b72d to
94aeef8
Compare
Add a check-container-runtime pipeline step that verifies the Docker/Podman daemon is running before container build steps execute. This prevents cascading failures where Docker-not-running errors cancel unrelated steps (like Azure provisioning), producing misleading credential errors. Changes: - Add WellKnownPipelineSteps.CheckContainerRuntime - Register the step in DistributedApplicationPipeline with interactive retry support (prompts user to start Docker in interactive mode) - ProjectResource and ContainerResourceBuilderExtensions wire build steps to depend on it - Fix CheckIfRunningAsync to check daemon only (remove buildx check) - Update tests and snapshots Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
davidfowl
force-pushed
the
davidfowl/deploy-delight
branch
from
94aeef8 to
ec99d35
Compare
Contributor
|
🎬 CLI E2E Test Recordings — 72 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #24597482751 |
Contributor
Author
|
Had to make a few more changes but this works well now |
radical
pushed a commit
to radical/aspire
that referenced
this pull request
Apr 18, 2026
…icrosoft#16196) Add a check-container-runtime pipeline step that verifies the Docker/Podman daemon is running before container build steps execute. This prevents cascading failures where Docker-not-running errors cancel unrelated steps (like Azure provisioning), producing misleading credential errors. Changes: - Add WellKnownPipelineSteps.CheckContainerRuntime - Register the step in DistributedApplicationPipeline with interactive retry support (prompts user to start Docker in interactive mode) - ProjectResource and ContainerResourceBuilderExtensions wire build steps to depend on it - Fix CheckIfRunningAsync to check daemon only (remove buildx check) - Update tests and snapshots 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.
Description
Add a container runtime health check as an orphan pipeline step that prevents cascading failures when Docker/Podman isn't running during deployment.
Problem: When Docker isn't running and a user runs
aspire deploy, the container build step fails and cancels sibling pipeline steps (like Azure provisioning) via the shared CancellationTokenSource. The cancelled provisioning step surfaces misleadingDefaultAzureCredentialerrors, burying the actual root cause.Solution: Add a
check-container-runtimestep to the pipeline that:IContainerRuntimeResolverto detect and verify the runtime.WellKnownPipelineSteps.CheckContainerRuntimeso third-party resources can depend on it too.Fixes #12348
Checklist
<remarks />and<code />elements on your triple slash comments?aspire.devissue: