fix: honor [SERVICE...] filter in config --no-interpolate - #13932
fix: honor [SERVICE...] filter in config --no-interpolate#13932TowyTowy wants to merge 1 commit into
Conversation
The `config --no-interpolate` and `config --variables` code paths render a raw model map (via ToModel/LoadModel) instead of a fully typed project, because unresolved interpolation variables may prevent a complete project load. ToModel accepted a `services` argument but never used it, so the [SERVICE...] command-line filter was silently dropped and every service was rendered regardless of the selection. Filter the model to the selected services and their transitive dependencies, mirroring how ToProject applies WithSelectedServices on the typed project. Dependency traversal and the "no such service" validation are delegated to compose-go's typed logic (Project.WithSelectedServices) by building a minimal project from the model's service names and depends_on edges, so a selected service correctly pulls in its dependencies rather than only itself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: TowyTowy <towy@airreps.link>
glours
left a comment
glours
left a comment
There was a problem hiding this comment.
Thanks for taking the time to dig into this!
However, the CLI is not the right place to fix it: the root cause is in compose-go, where service selection was only applied on the typed path (LoadProject) and silently ignored by the raw-model path (LoadModel) used by config --no-interpolate.
Filtering the model here re-implements loader logic in the CLI, and would also introduce a regression: under --no-interpolate, a literal depends_on: ["${VAR}"] would fail with no such service: ${VAR}.
This is now fixed upstream in compose-spec/compose-go#896. Once a release including it is vendored here, the fix on the compose side reduces to passing cli.WithSelectedServices(services...) in ToModel. If you're up for reworking this PR into that once the bump lands, your test cases would be valuable to keep.
|
We decided to just warn users that the service filtering won't be applied when using the |
2 participants
What I did
docker compose config --no-interpolate <SERVICE>(andconfig --variables <SERVICE>) ignored the[SERVICE...]argument and rendered every service. These paths build a raw model viaToModel/LoadModelinstead of a fully typed project (unresolved interpolation variables can block a full load), andToModelaccepted aservicesargument that was never applied.This filters the model to the selected services and their transitive dependencies, matching the interpolated path (
ToProject→WithSelectedServices). Rather than reimplement dependency traversal on the raw map, it builds a minimal typed project from the model's service names anddepends_onedges and delegates to compose-go'sProject.WithSelectedServices, so a selected service correctly pulls in its dependencies (and unknown services raise the sameno such serviceerror). Both short-list and long-mapdepends_onforms are handled, so it works with--no-normalizetoo.This supersedes the approach in #13637 (closed): as noted there, a SERVICE selection must enable the target and its dependencies, which this implements by reusing compose-go's typed logic. Added regression + unit tests (fail before, pass after);
go test ./cmd/compose/,go vet, and golangci-lint all clean.Related issue
Fixes #13614
Disclosure: prepared with AI assistance (Claude); authored, reviewed, and tested by me. Co-authorship noted in the commit trailer.