# Objective

Docker Compose devcontainers currently resume only the primary container
when an existing environment is stopped. Supporting services listed in
`runServices`, such as databases and caches, remain stopped.

Fixes #60779

## Solution

Reuse the Docker Compose startup path when resuming an existing
Compose-based devcontainer.

The resume path now:

- Runs `docker compose up -d --no-recreate`.
- Targets the services configured in `runServices`.
- Uses the original Compose files and project name.
- Avoids recreating the existing devcontainer.
- Preserves the existing `docker start` behavior for non-Compose
devcontainers.

A regression test verifies that the requested services are resumed,
unrelated services are excluded, and the existing container is not
recreated.

## Testing

Tested on macOS with:

- `cargo fmt --all --check`
- `cargo test -p dev_container`
- `cargo clippy -p dev_container --tests -- -D warnings`

All 112 `dev_container` tests pass.

Also tested against a multi-service Docker Compose devcontainer
containing a workspace, web server, PostgreSQL, Redis, and Celery. All
configured services resumed while the workspace container retained the
same container ID.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

## Release Notes:

- Fixed Docker Compose dev containers not starting all configured
services when resuming an existing environment.

---------

Co-authored-by: dino <dinojoaocosta@gmail.com>