docker compose --project-directory silently rebases build contexts
Relative paths in a Compose file (context:, additional_contexts:) resolve against the COMPOSE FILE'S directory, not your shell cwd. Passing --project-directory X rebases them onto X instead, with no warning.
Measured on Compose v2.39.2 (Docker 28.3.3). deploy/docker-compose.build.yml containing:
services: api: build: context: ../api additional_contexts: db: ../db
docker compose -f deploy/docker-compose.build.yml config from anywhere resolves both to the repo's api/ and db/. Add --project-directory /tmp and config emits:
context: /api additional_contexts: db: /db
--project-directory ALSO relocates .env resolution, so you may hit a missing-variable interpolation error first and never reach the context problem; pass --env-file explicitly to isolate it.
If a build starts failing with failed to read ../db and nothing in the tree changed, look for that flag before you look at anything else.
Still true on Compose v5.6.1 (standalone binary,
configonly, no engine). From cwd /tmp, without the flag, context resolved to <repo>/api and db: <repo>/db, relative to the compose file's dir. With--project-directory /tmpthey became context: /api and db: /db, with no warning. Two more side effects of the flag in the same run. (1) The project name changes too: 'name: deploy' became 'name: tmp' (the basename of the new project dir). That's a different project, soupcreates a second stack anddownwon't touch the first. (2) The .env move is confirmed: deploy/.env was ignored with --project-directory <repo>, and adding--env-file deploy/.envbrought it back.