v0.2.0 — stop the whole Compose project

Important

prefix+S now stops more than it used to. On a Compose-based Dev Container, stop takes down every service in the project, not just the one the pane runs in. For a project with a database, cache, and gateway, that is one keystroke stopping six containers instead of one. The confirmation names every container before anything happens, and still proceeds only on an explicit y.

Stop means the whole Compose project

A Compose-based Dev Container is one service among several. Stopping only it left postgres, redis, and everything else running after the user asked to stop the Dev Container. That is also what devcontainer.json asks for: shutdownAction defaults to stopCompose for Compose configs, which is what VS Code does on disconnect.

Project membership comes from the container's own com.docker.compose.project label — the label Compose itself uses — so nothing here re-derives a project name from devcontainer.json.

stop 6 containers for /home/you/workspace/app?
  app               app_devcontainer-app-1               dc08b7aeca6f
  supabase-gateway  app_devcontainer-supabase-gateway-1  293672c080bb
  gotrue            app_devcontainer-gotrue-1            774e6d94d1c3
  redis             app_devcontainer-redis-1             f33d5de3a11e
  postgres          app_devcontainer-postgres-1          6cc33c601af0
  inbucket          app_devcontainer-inbucket-1          348a5d6e757b
[y/N]:

A single-container repository renders exactly as it did before.

Details that matter in practice

• The Dev Container stops first, in its own docker stop call, and is waited on — so it releases its database connections before the database goes down. This needs a separate call: docker stop a b c stops the named containers in parallel, and argument order only controls the order results print.
• docker compose run containers are left alone, matching docker compose stop. A compose run --rm app pytest running in another pane survives.
• An exited Dev Container no longer hides a running project. If the app container exits on its own — a crash, an OOM kill, a stop from another pane — while its services keep running, v0.1.2 reported "no running dev container" and exited 0. Its survivors are now reported and offered for stopping.
• Whether the stop worked is asked of docker, not inferred from docker stop's output. On timeout the CLI is killed and its output says nothing about what landed, so the most likely partial stop was the one that reported the least. Anything still running is named in the error.

Upgrade

herdr plugin install gambtho/herdr-devcontainer --ref v0.2.0

If you prefer the old single-container behavior, stay pinned to --ref v0.1.2.

Full changelog: v0.1.2...v0.2.0