Track Compose compatibility gaps found with apple/container 1.0.0

[thromel]

Summary

This tracks a small set of Compose compatibility gaps found while testing container-compose 1.0.0 with apple/container 1.0.0 on macOS 26.5.1.

The goal is to keep the work contribution-friendly: each linked issue is narrow enough to fix or validate independently.

This tracker is for Compose compatibility work in container-compose. Runtime-level fixes should happen upstream in apple/container; the main one from this test run is container name/service DNS.

Environment used for the repros

- OS: macOS 26.5.1 (25F80)
- Xcode: 26.5 (17F42)
- container: 1.0.0 (release, commit ee848e3)
- container-compose: 1.0.0 installed via Homebrew
- Architecture: arm64

Issues

• Services on the same Compose network cannot resolve service names #114
  Services on the same Compose network cannot resolve service names.

• One-shot services are reported as startup timeouts and failures can exit 0 #115
  One-shot services are reported as startup timeouts and failures can exit 0.

• Parse Compose service network object form for aliases #116
  Parse Compose service network object form for aliases.

• healthcheck and depends_on service_healthy are silently ignored #117
  healthcheck and depends_on: condition: service_healthy are silently ignored.

• Named container workaround fails when container copies data into it #52
  Named volume workaround fails; native container run -v data:/data ... now appears to support named volumes directly.

Upstream dependencies / related Apple Container issues

• [Bug]: internal DNS does not work (clean install) apple/container#856
  Container name DNS resolution currently fails in a plain container repro on container 1.0.0. This likely affects Services on the same Compose network cannot resolve service names #114 and is the best first candidate for an upstream apple/container contribution.

• Support Docker Compose-compatible container log semantics apple/container#1752
  Tracks log retrieval semantics needed by Compose-compatible orchestrators. Not part of the first repro batch, but relevant for future container-compose logs work.

Suggested contribution order

1. One-shot services are reported as startup timeouts and failures can exit 0 #115: fix one-shot service wait semantics and CLI exit status.
   This should be mostly internal container-compose behavior and is easy to regression-test.

2. Parse Compose service network object form for aliases #116: accept Compose network object syntax.
   Even if aliases cannot fully work until service discovery improves, the YAML shape should decode cleanly.

3. Named container workaround fails when container copies data into it #52: switch named-volume handling to native container named volumes where supported.
   The current workaround looks stale against container 1.0.0.

4. healthcheck and depends_on service_healthy are silently ignored #117: either implement healthcheck/dependency behavior or emit a clear unsupported-feature error.
   Silent ignore is the risky part.

5. Services on the same Compose network cannot resolve service names #114: track Apple Container DNS/service discovery behavior.
   If upstream runtime support is required, the immediate improvement may be documentation, warning output, and tests that mark the limitation explicitly.

Definition of done

• Minimal repro compose files for each issue are added as tests or fixtures.
• Commands return non-zero when startup fails.
• Successful one-shot services are not reported as timeouts.
• Unsupported Compose features produce clear diagnostics instead of silent behavior differences.
• The tracker checklist above is updated as issues are fixed or determined to be upstream-only.

[thromel]

Update from local validation and PR work:

• Container-Compose PR: Improve Apple container compose compatibility #119
• Apple runtime feature request for Compose-style bare DNS/aliases: [Request]: First-class container-to-container DNS discovery on custom networks apple/container#1809
• Apple DNS-normalization PR for the embedded DNS lookup path: Normalize network hostname lookup apple/container#1810
• Existing Apple DNS discussion/repro: [Bug]: internal DNS does not work (clean install) apple/container#856

The Container-Compose PR addresses named volumes, one-shot dependency handling, healthcheck gating, dependency-condition parsing, network object parsing, and alias warning behavior. Full Compose-style service discovery still depends on Apple runtime support for network-scoped DNS/aliases.

[thromel]

Additional Apple-side contribution now linked from the compose PR: apple/container#1811 proposes a native container run --hostname flag. Container-Compose PR #119 intentionally warns and skips Compose hostname: when targeting Apple Container 1.0.0, then points to that upstream path for proper runtime support.

[thromel]

Upstream update: I opened apple/container#1813 as a draft for the container-facing DNS layer.

Current upstream chain:

• Normalize network hostname lookup apple/container#1810: normalize hostname lookup/trailing-dot handling
• Add DNS forwarding groundwork apple/container#1813: add a container-facing DNS listener so bare container hostnames can resolve through the vmnet gateway
• [Request]: First-class container-to-container DNS discovery on custom networks apple/container#1809: central tracking issue for Compose-style service discovery and aliases

This should cover the bare service-name/container-name DNS path once accepted upstream. Explicit per-network aliases are still not implemented in apple/container yet, so Container-Compose alias support should remain blocked on that upstream API/CLI surface.

[thromel]

Another upstream update: apple/container#1815 is open as a draft for explicit network aliases.

Current upstream chain:

• Normalize network hostname lookup apple/container#1810: normalized/trailing-dot hostname lookup
• Add DNS forwarding groundwork apple/container#1813: container-facing DNS listener and forwarding
• Add network attachment aliases apple/container#1815: network attachment aliases via --network name,alias=...
• [Request]: First-class container-to-container DNS discovery on custom networks apple/container#1809: central service-discovery/alias tracker

Once the Apple-side PRs settle, Container-Compose can map Compose service/network aliases onto the upstream alias= attachment property instead of carrying a workaround.

[thromel]

Container-Compose PR #119 now includes a conditional alias mapping path:

• when the linked Apple container command parser accepts --network name,alias=..., Compose network aliases are emitted as Apple network alias properties
• when linked against Apple Container 1.0.0, it preserves the existing warning/skip behavior instead of passing an unsupported property

That keeps #119 compatible with current Apple Container while making it ready for the alias surface proposed in apple/container#1815.

[thromel]

Upstream status update:

• Add DNS forwarding groundwork apple/container#1813 is now ready for review. It covers the bare container hostname DNS path through the vmnet gateway and keeps an explicit RFC note for the wildcard UDP 53 binding design.
• Add network attachment aliases apple/container#1815 has been rebased on top of the updated DNS stack and adds explicit --network name,alias=... attachment aliases with additional serialization/client plumbing coverage. It remains draft until the live alias smoke gap is resolved.
• Container-Compose PR Improve Apple container compose compatibility #119 is still correctly conditional: current Apple Container keeps warning/skipping aliases, while future Apple builds that accept alias= can receive Compose aliases directly.

[thromel]

Status update: Container-Compose PR #119 is now marked ready for review.

It remains compatible with Apple Container 1.0.0 by warning/skipping unsupported alias and hostname flags, while carrying conditional paths for the upstream Apple features proposed in apple/container#1811 and apple/container#1815.

[thromel]

Upstream status update: apple/container#1815 is now ready for review.

The alias PR has live validation for --network name,alias=... resolving aliases through gateway DNS, plus duplicate-alias rejection. That means Container-Compose PR #119's conditional alias path now has a validated upstream target while still preserving Apple Container 1.0.0 fallback behavior.

[ryan106]

Went through this whole tracker against current main while working on #126 (Compose profiles support). Looks like #119 (merged the same day this tracker was opened) already fixed everything except the DNS item:

• Named container workaround fails when container copies data into it #52 (named volumes) — fixed; tested the exact WordPress repro from that issue, see my comment there
• One-shot services are reported as startup timeouts and failures can exit 0 #115 (one-shot exit codes/timeouts) — fixed; tested both the successful and failing one-shot cases, see my comment there
• Parse Compose service network object form for aliases #116 (network object form for aliases) — fixed; NetworkConfigurationTests.swift already covers the exact YAML shape from the issue and it decodes cleanly
• healthcheck and depends_on service_healthy are silently ignored #117 (healthcheck/depends_on: condition) — fixed; service_healthy/service_completed_successfully/service_started are all implemented with real healthcheck polling and clear errors for anything unrecognized, see my comment there
• Services on the same Compose network cannot resolve service names #114 (service-name DNS) — still open, as expected, blocked on apple/container#856 upstream

So this tracker is effectively done modulo #114, which isn't fixable here. Might be worth closing #52/#115/#116/#117 individually and leaving this issue open just to track #114, or closing this one too and letting #114 stand alone — your call on how you like to manage the tracker.

[thromel]

Thanks for validating this against current main. I agree with that split.

I closed #115, #116, and #117 as completed by #119. #52 also appears resolved by #119 based on the WordPress repro validation, but I do not have permission to close an issue opened by another user, so a maintainer will need to close that one.

I am leaving #114 open as the remaining live item, since Compose service-name DNS still depends on Apple Container runtime support rather than another Container-Compose parser/orchestration fix.