compose: add --all flag to down for full cleanup

[sarika-03]

What I did

Added a new --all flag to docker compose down so users can fully clean up a Compose project, including resources created under inactive profiles.

Changes included

• added --all to docker compose down
• made down --all load the project with all profiles enabled
• made down --all include orphan containers automatically
• ensured associated networks and volumes are also cleaned up
• added unit and e2e coverage for inactive-profile cleanup
• updated down command help and docs

Manual verification

• reproduced the bug with a profiled service (bar)
• docker compose down -v -t 0 --remove-orphans left the profiled container, network, and volume behind
• docker compose down --all -v -t 0 removed all remaining project resources

Related issue

Fixes #13647
Related to #13027

Cute animal 🐳

[sarika-03]

@ndeloof @glours
please review my PR

[ndeloof]

using --profile=* already offers this feature

[sarika-03]

@ndeloof , Thanks for pointing that out.

Using --profile="*" does allow including all profiles, but it’s not very discoverable and requires users to know this internal detail.

The goal of --all is to provide a simple and consistent way to fully clean up a Compose project, similar to other Docker commands that expose an explicit --all flag (e.g., docker system prune --all).

It avoids the need for users to reason about profiles when they just want a full reset of the project.

[glours]

Thanks for the contribution! The underlying problem (inactive profiles surviving down) is real and worth solving.

However, we have concerns about the --all flag as proposed:

Naming ambiguity: --all in existing Compose commands (ps --all, ls --all) means "include containers/projects in states normally filtered out." This PR redefines it to mean "activate all profiles + force orphan removal" which is a different semantic. Users will reasonably expect down --all to also remove volumes and images, but it doesn't (you still need -v and --rmi). This will lead to confusion: "I used --all but my volumes are still there."

--profile=* already works: As @ndeloof pointed out, docker compose --profile=* down -v --remove-orphans already achieves the same result today. The gap is discoverability, not functionality.

Hidden side-effects: --all silently forces --remove-orphans even if the user didn't ask for it. These should remain orthogonal flags the user composes explicitly.

Suggestions:

1. Preferred: Improve discoverability of --profile=* by adding examples to down --help (e.g., docker compose --profile='*' down -v --remove-orphans for full cleanup)
2. If a dedicated flag is needed: Consider --all-profiles, it says exactly what it does, stays orthogonal to -v/--rmi/--remove-orphans, and avoids the naming collision with existing --all semantics

[sarika-03]

@glours Thanks for the detailed feedback this makes a lot of sense.

I agree that overloading --all introduces ambiguity, especially given its existing meaning in other Compose commands, and that it could lead to incorrect expectations around volumes/images cleanup.

Also agreed that --profile="*" already provides the underlying functionality, and the main gap here is discoverability and usability.

Based on your suggestion, I can update the PR to:

1. replace --all with a more explicit --all-profiles flag
2. keep it orthogonal to other flags (i.e, not implicitly enabling --remove-orphans)
3. ensure behavior is limited strictly to profile expansion
   4 . improve help text with examples including --profile="*" usage

Let me know if this direction aligns better with the intended design.

[glours]

@sarika-03, as I said, I’d prefer that we improve discoverability first. We already have everything in place, we just need to make it more explicit to users. It’s a low-cost change and something we should be able to merge quickly.

We’ll still need to discuss with @ndeloof the pros and cons of adding a new flag to the command, so I’d rather not have you spend time on something that may ultimately not be merged, for now.

[sarika-03]

@glours I agree
@ndeloof please share your opinion