← ClaudeAtlas

dockerlisted

Docker/OCI doctrine — one shared multi-stage Dockerfile per repo, the same digest promoted rather than rebuilt per environment, and Compose as the local stack behind `wait-on` readiness gates (vwf's one non-negotiable harness mechanism). Auto-applies when editing a Dockerfile, a compose file, or .dockerignore.
virajp/ai-plugins · ★ 1 · DevOps & Infrastructure · score 78
Install: claude install-skill virajp/ai-plugins
# Docker & OCI images Containers do two unrelated jobs in this toolkit, and conflating them is the usual mistake: 1. **The deploy artifact** — one OCI image per deployable project, built once and promoted between environments. That is the `container-generic` deploy template this plugin ships, offered through `/devtools:devtools-stack-menu`. 2. **The local stack** — the backing services `e2e_local` needs, run under Compose. This is the one harness capability whose *mechanism* vwf fixes. A repo may need either, both, or neither. A product whose `e2e_local` needs no backing services needs no Compose file, and a `frontend` project that ships through a store needs no image at all. ## One Dockerfile per repo, not per project A monorepo builds every deployable from **one shared multi-stage Dockerfile**, parameterized by the target project. It builds the workspace, prunes to that project's production closure, and produces a minimal runtime image. One file rather than one per project because the divergence between them is almost always accidental — a base-image bump applied to three of five services is a class of drift nothing catches until something breaks in only one environment. Parameterize what genuinely differs; do not fork the file. The image carries **no environment-specific configuration and no provider-specific entrypoint or agent**. Configuration arrives as environment variables from the host, which is what lets the same digest be promoted from `staging`