Summary
The three service Docker builds (manager, feeder, frontend) currently share a build context (the repo root), which forces them to run sequentially to avoid I/O contention. Decoupling them would allow parallel builds and significantly reduce deployment time.
Current Behavior
All three services use the repo root as build context via -f <service>/Dockerfile ., meaning Docker sends the entire repo to the daemon for each build. Running them in parallel causes I/O contention over the shared context.
Proposed Changes
- Give each service its own self-contained build context (e.g. each
Dockerfile only references files within its own directory, or uses a .dockerignore / multi-stage copy to limit context)
- Alternatively, restructure Dockerfiles to use targeted
COPY instructions so each build only needs its own service directory, allowing independent parallel builds
- Update the deploy-to-minikube skill/scripts to run builds concurrently once decoupled
Expected Benefit
- Faster local build + deploy cycle (3 sequential builds → 3 parallel builds)
- Reduced resource contention during builds
- Cleaner separation of service build dependencies
Summary
The three service Docker builds (manager, feeder, frontend) currently share a build context (the repo root), which forces them to run sequentially to avoid I/O contention. Decoupling them would allow parallel builds and significantly reduce deployment time.
Current Behavior
All three services use the repo root as build context via
-f <service>/Dockerfile ., meaning Docker sends the entire repo to the daemon for each build. Running them in parallel causes I/O contention over the shared context.Proposed Changes
Dockerfileonly references files within its own directory, or uses a.dockerignore/ multi-stage copy to limit context)COPYinstructions so each build only needs its own service directory, allowing independent parallel buildsExpected Benefit