Report unsupported WSLc Dockerfile build options before runtime readiness errors

Open
  • Is something wrong?
#21,885 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
backend, devops, testing

Research direction

Start with ContainerResourceBuilderExtensions.EnsureBuildAndPushPipelineAnnotations, ResourceContainerImageManager.BuildImageAsync, and WslcContainerRuntime.BuildImageAsync to trace validation and readiness ordering in both entry points. Check the existing SDK publishing validation and add regression coverage for unsupported platform or archive options with a stopped runtime, alongside supported build recovery. Done means capability errors appear before readiness errors without evaluating build-option callbacks twice or probing runtime health for rejected builds.

Written by the indexing model from the issue text.

Description

area-orchestrator
Is there an existing issue for this?
  • I have searched the existing issues
Describe the bug

When WSLc is selected but not running, an unsupported Dockerfile publishing configuration reports a runtime-readiness error before reporting the capability limitation. Starting WSLc and retrying then reveals that the requested build could never succeed with that runtime.

For example, Dockerfile publishing defaults to a selected linux/amd64 platform, but WSLc does not support Dockerfile build platform selection. This is a diagnostic-order issue; the unsupported build is still rejected before execution.

Expected Behavior

Report the unsupported Dockerfile option and supported alternatives before attempting runtime readiness checks or prompting the user to start WSLc. Preserve existing readiness recovery for supported builds.

The behavior should be consistent through both the image manager and the normal publish/deploy pipeline.

Steps To Reproduce

On Windows with the WSLc publishing support from #21009:

  1. Configure an AppHost with a Dockerfile resource, leaving the default publish target platform in place:
var builder = DistributedApplication.CreateBuilder(args);
builder.AddDockerfile("service", "./service");
builder.Build().Run();
  1. Select WSLc with ASPIRE_CONTAINER_RUNTIME=wslc and ensure its runtime/session is stopped.
  2. Run the image-build pipeline, for example aspire do build --apphost <apphost-path> --non-interactive.
  3. Observe a runtime-readiness error. Start WSLc and retry; the operation then reports that platform-selected Dockerfile builds are unsupported.

These steps describe the code-path ordering identified during review; a stopped-session live reproduction has not been performed for this follow-up.

Exceptions (if any)

Depending on the entry point, runtime readiness reports that WSLc is not running or unhealthy. After readiness succeeds, the capability check reports:

WSLc does not support selecting a platform for Dockerfile image builds. Use Docker or Podman, or set TargetPlatform to null with WithContainerBuildOptions to build for the WSLc host platform.
Aspire doctor output

N/A — follow-up identified by tracing publishing validation and readiness ordering.

Anything else?

Follow-up to #21009 and https://github.com/microsoft/aspire/pull/21009#discussion_r4487899820.

Relevant code:

// ContainerResourceBuilderExtensions.EnsureBuildAndPushPipelineAnnotations
DependsOnSteps = [WellKnownPipelineSteps.BuildPrereq, WellKnownPipelineSteps.CheckContainerRuntime]

The Dockerfile build step depends on the pipeline's runtime health check, so moving validation only within ResourceContainerImageManager.BuildImageAsync will not correct normal CLI execution ordering. The manager also performs its own health check before invoking WslcContainerRuntime.BuildImageAsync, where unsupported Dockerfile options are currently rejected.

Address both entry points without evaluating container build-option callbacks twice or introducing inconsistent resolved options. The SDK publishing path already rejects its unsupported WSLc configurations before its per-build readiness check.

Suggested regression coverage: stopped runtime plus unsupported platform/archive options should report the capability limitation first through direct-manager and pipeline execution paths; supported Dockerfile builds should retain existing health checks and interactive startup recovery. Pure capability rejection should not invoke the runtime health probe.

Dominant language
C#
Stars
6.4k
Forks
1k
Avg merge
3d 3h
Merged PRs (30d)
406

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/aspire

All issues in microsoft/aspire

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.