Repository navigation
Track Compose compatibility gaps found with apple/container 1.0.0 #118
Description
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: arm64Issues
-
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
healthcheckanddepends_on: condition: service_healthyare silently ignored. -
Named container workaround fails when container copies data into it #52
Named volume workaround fails; nativecontainer 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 plaincontainerrepro oncontainer1.0.0. This likely affects Services on the same Compose network cannot resolve service names #114 and is the best first candidate for an upstreamapple/containercontribution. -
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 futurecontainer-compose logswork.
Suggested contribution order
-
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 internalcontainer-composebehavior and is easy to regression-test. -
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. -
Named container workaround fails when container copies data into it #52: switch named-volume handling to native
containernamed volumes where supported.
The current workaround looks stale againstcontainer1.0.0. -
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. -
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.
Activity
thromel commentedon Jun 25, 2026
Update from local validation and PR work:
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 commentedon Jun 25, 2026
Additional Apple-side contribution now linked from the compose PR: apple/container#1811 proposes a native
container run --hostnameflag. Container-Compose PR #119 intentionally warns and skips Composehostname:when targeting Apple Container 1.0.0, then points to that upstream path for proper runtime support.thromel commentedon Jun 25, 2026
Upstream update: I opened apple/container#1813 as a draft for the container-facing DNS layer.
Current upstream chain:
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 commentedon Jun 25, 2026
Another upstream update: apple/container#1815 is open as a draft for explicit network aliases.
Current upstream chain:
--network name,alias=...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 commentedon Jun 25, 2026
Container-Compose PR #119 now includes a conditional alias mapping path:
containercommand parser accepts--network name,alias=..., Compose network aliases are emitted as Apple network alias propertiesThat keeps #119 compatible with current Apple Container while making it ready for the alias surface proposed in apple/container#1815.
thromel commentedon Jun 25, 2026
Upstream status update:
--network name,alias=...attachment aliases with additional serialization/client plumbing coverage. It remains draft until the live alias smoke gap is resolved.alias=can receive Compose aliases directly.thromel commentedon Jun 25, 2026
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 commentedon Jun 25, 2026
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 commentedon Jul 2, 2026
Went through this whole tracker against current
mainwhile working on #126 (Composeprofilessupport). Looks like #119 (merged the same day this tracker was opened) already fixed everything except the DNS item:NetworkConfigurationTests.swiftalready covers the exact YAML shape from the issue and it decodes cleanlyservice_healthy/service_completed_successfully/service_startedare all implemented with real healthcheck polling and clear errors for anything unrecognized, see my comment thereapple/container#856upstreamSo 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 commentedon Jul 2, 2026
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.
Mcrich23 commentedon Sep 9, 2026
Thank you for tracking these and following up with the upstream work. The original items are addressed except for service-name DNS, which already has #114. I'm closing this tracker so we can keep the remaining work there. The additional healthcheck and completion cases are being addressed in #151 and #154.