fix(compose): run Compose on the resolved runtime, not a literal docker

[pofallon]

Closes #710. Closes #706.

What was wrong

deacon ran docker compose no matter which runtime it had resolved. Under --runtime podman the service image was built into docker's store, and every podman-side step after it — tag, run, exec — reported image not known.

Two layers, both wrong for different reasons:

• deacon build's compose path built its ComposeManager with ComposeManager::new(), whose docker_path defaults to the literal "docker". That ignored --docker-path as well, not just --runtime.
• up, down, exec, up's port-event handler and read-configuration each passed the raw --docker-path flag. binary_for maps an untouched default to the flavor's own name only inside resolve_runtime, so with no explicit path the flag still read "docker".

Same class as #708, one layer up: the command validated against the resolved runtime and then invoked a different one.

Measured

Shim on --docker-path (logs argv, execs the real binary), real compose config:

	compose invocations reaching the named binary
build, before	0 — only -v, image inspect, tag
build, after	3, the service build among them
up --runtime podman, before	0 — only ps, inspect
up --runtime podman, after	6, plus every ps / inspect / exec

Two false diagnoses, corrected in the ledger

Both prior localhost/ attempts on #706 were derived from a naming diagnosis and both were measured wrong. They could not have worked: the image was in another daemon's store, so no spelling would find it.

The follow-up issue's own hypothesis was false too — it supposed podman's external compose provider talks to the docker daemon. Measured by pointing compose_providers at a script that dumps its environment, podman does the opposite: it points the provider at its own socket, exporting DOCKER_HOST=unix:///run/podman/podman.sock (plus DOCKER_BUILDKIT=0 and an emptied DOCKER_CONFIG). deacon never reached that delegation.

A compensation removed with it

execute_compose_lifecycle deliberately built its exec client from --docker-path rather than the resolved runtime, with a comment recording that docker compose created the project in the docker daemon so podman exec could not find it. That was a correct workaround for the wrong split — and would have re-opened the gap from the other side now that compose follows the runtime. It follows runtime_bin like everything else.

Guard

build_runtime_routing::compose_build_runs_on_the_runtime_named_by_docker_path — hermetic, no daemon, #[cfg(unix)]. Sabotage-verified: reverting the build fix fails it with exactly the pre-fix log (-v, image inspect, and nothing else).

Verification

• make test-nextest-fast — 3678 passed
• integration_compose_features_build on Docker — 7/7
• compose + read-configuration suites — 84 passed
• down / exec / runtime-selection — 41 passed
• fmt + clippy --all-targets --all-features clean

integration_compose_features_build returns to the Podman CI step as a whole binary; that lane goes from 29 selected tests to 36.

🤖 Generated with Claude Code

https://claude.ai/code/session_016SFzA2sTh2EpX8MZU3TWNS

[pofallon]

Validated against real rootless podman

I got podman working properly in the devcontainer (#716) and re-measured this on a genuine podman substrate instead of reasoning about it. Two corrections to the PR as it stood, both pushed in f1221dc.

The lane needed podman's API socket started, and its setup step explicitly disclaimed one (# deacon's PodmanRuntime drives the podman CLI directly (no socket)). Since podman compose execs an external provider and points it at that socket via DOCKER_HOST, every compose call would have failed with Cannot connect to the Docker daemon — a fact about the job, not about deacon. Started directly rather than through systemctl --user, so the lane doesn't depend on a user systemd session existing on the runner image.

Three of the seven hit a fourth capability gap and stay excluded, by name, alongside the three buildx exporter gaps. Podman sets DOCKER_BUILDKIT=0 for the compose provider, pinning docker-compose to the classic builder; deacon passes Feature content as an additional build context, which only BuildKit supports:

the classic builder doesn't support additional contexts, set DOCKER_BUILDKIT=1 to use BuildKit

Only build:-shape services hit it — the image: shape builds its Feature image with podman build directly.

Measured result

4 of 7 pass, including compose_features_image_shape_installs_feature — the test #706 was originally filed about. The three failures are the BuildKit gap above, confirmed individually rather than assumed from one sample.

The lane selects 30 tests, not the 26 it did before. I'd earlier written "36" in the ledger; that was a shell-quoting artifact in my own verification command, and it's corrected.

What this changes about the fix itself

Nothing — it confirms it. On real podman, podman compose build puts its image in podman's own store, where podman tag finds it and podman run executes it. That was the exact operation #710 reported as impossible under every spelling, and it was impossible only because deacon was running docker compose.

[pofallon]

Podman lane was red; fixed in 246567a

Four failures out of 433, and all four are the same test defect #705 already fixed in integration_build{,_output} — the assertion shells out to a hardcoded docker to inspect what deacon produced, reading a different daemon than the deacon under test wrote to.

deacon::smoke_compose_edges            test_compose_down_stops_but_keeps_containers
deacon::smoke_compose_override_command test_compose_override_command_default_keeps_service_alive
deacon::smoke_compose_override_command test_compose_override_command_lifecycle_runs
deacon::smoke_compose_override_command test_compose_override_command_explicit_false_runs_natural_command

They passed before only because compose itself also ran on docker. Moving the compose client onto the resolved runtime moved the containers to podman and left the assertions looking in the old place, so docker exec <id> couldn't find a container that exists. It surfaced as:

postCreateCommand should have created /tmp/deacon-lifecycle-marker

which reads like a lifecycle bug and isn't one — worth flagging, because that message would send the next person after the wrong thing.

Uses the existing support::runtime_bin() rather than adding a ninth per-file copy of the helper.

Verified

• under real rootless podman 4.9.3: 10/10 (was 6/10)
• on docker: 10/10 — runtime_bin() returns "docker" by default, so no behavior change there
• CI's full failure set was exactly these four; Test (MVP integration) (docker) was already green

This is the honest-lane effect from #708 showing up one layer further out: the fix didn't break these tests, it stopped them from being verified against the wrong daemon.