Repository navigation
Refactor Docker Compose for per-service and whole-suite testing #37
Description
Problem
The only compose file is apps/stacker/docker-compose.yml, and it still references pre-consolidation relative paths that broke during the Phase 2 monorepo consolidation:
retriever-apibuild context:../retriever/backend(retriever'sbackend/was flattened to the service root; correct path is now../../services/retriever)petdata-apibuild context:../petdata(the top-level module dirs were removed; correct path is now../../services/petdata)env_fileentries point at the same stale paths
There is also no way to bring up or test a single service in isolation: the compose file is portal-centric and couples all backends together under apps/stacker.
Desired outcome
Docker setup that supports both:
- Per-service: build, run, and test one service (petdata, retriever, or future biowriter) on its own.
- Whole-suite: bring up the full stack (Postgres/pgvector, all services, the portal's backends) with one command.
Possible direction (not prescriptive)
- Move compose to a repo-level
infra/(or root) location so paths resolve cleanly across the monorepo, per the target layout indocs/plans/repo-restructure-and-rename.md. - Per-service compose files or compose profiles, with a top-level compose that composes them for the full suite.
- Align with the tech-stack standard's "one-command local stack" goal (Phase 5 / ADR 0003).
Acceptance Criteria
- A single service can be built and run in isolation via Docker (documented command).
- The whole suite (db + services) comes up with one command.
- All build contexts and
env_filepaths resolve correctly from the monorepo layout (no../petdata/../retriever/backendstale paths). - The approach is documented (README or
infra/docs) and consistent with the tech-stack standard's one-command local stack.
Notes
- Surfaced during Phase 3 (PR refactor(petdata): rename petbio to petdata and scrub FOHA (Phase 3) #36), which only renamed tokens inside the existing compose file and explicitly deferred the topology fix here.
- Housekeeping aside: the
module:petbiolabel is now mislabeled (service ispetdata); consider renaming the label tomodule:petdata.
Activity
ckrough commentedon Jun 24, 2026
daedalus pipeline claimed
ckrough commentedon Jun 24, 2026
daedalus pipeline: BLOCKED (spec contradicts code)
The pipeline halted before implementation because the issue's premise no longer matches the repository. The conditions described here were fixed by the monorepo consolidation and follow-on work that landed after this issue was filed (it references PR #36 / Phase 3). Marking blocked for an operator decision rather than fabricating out-of-scope changes.
Premise in the issue vs. current
main:apps/stacker/docker-compose.yml" with stale../retriever/backendand../petdatabuild contexts andretriever-api/petdata-apiservices.mainhas four compose files, already reorganized per service:services/retriever/docker-compose.yml(dev pgvector + Jaeger)services/retriever/docker-compose.test.yml(ephemeral test DB, :5433)services/petdata/docker-compose.test.yml(ephemeral test DB, :5434)apps/stacker/docker-compose.yml(app database for the portal, :5433)grepfor../petdata,../retriever/backend,retriever-api,petdata-apiacross all compose files returns nothing.Acceptance criteria, current status:
env_filepaths): satisfied. No stale paths remain anywhere.make dev(Supabase + pgvector + migrations + services),make downto stop. Targets live in the rootMakefile.docs/local-development.md(manualmaketargets).docs/local-development.md.The "housekeeping aside" is also already done: the
module:petbiolabel no longer exists.Residual ambiguity for the operator (not in the binding acceptance criteria):
services/petdatahas no serviceDockerfile(only a test-DB compose), so petdata cannot be built-and-run as a container in isolation the way retriever can (retriever has aDockerfile). The current model runs services natively against dockerized datastores.infra/compose; the suite is composed via theMakefile, not a parent compose file. Both were listed in the issue only as "possible direction (not prescriptive)."Recommended operator action: close as already-resolved by the monorepo consolidation, OR re-scope to the two residual items above (petdata service Dockerfile and/or a top-level
infra/compose) if those are still wanted, then re-dispatch.Pipeline state: no branch work done, nothing committed, working tree clean (nothing to stash). Bindings followed: tracker=github, push_policy=gated, close_semantics=on-merge. Worktree:
issue/37atclaude-worktrees/evermore-issue-37.ckrough commentedon Jun 24, 2026
Resolved by the monorepo consolidation (Phase 3) and follow-on work. The stale compose paths and
retriever-api/petdata-apiservices this issue described no longer exist onmain: four per-service compose files now exist,make dev/make downgive whole-suite up/down, and per-service isolation is documented indocs/local-development.md. The one genuinely-missing artifact, a petdata service Dockerfile, is tracked separately in #8. The non-prescriptive 'top-level infra/ compose' idea is superseded by the Makefile-over-per-service-compose model. Closing as already-resolved; no code change needed.