You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new service: directive for additional_contexts almost fulfills the dream of letting docker/docker-compose become highly usable in a monorepo scenario, where images depend on other images built on demand in the same repository. See https://stackoverflow.com/a/79487072/95653 for an 8-year-old question in that direction finally getting an answer.
However, the build time dependency created by the additional context is not represented anywhere, and as a result, most commands break. Please review the example below, which is adapted from the aforementioned Stack Overflow answer.
If you run docker compose build, everything works as expected. However, if I do docker compose build b, I get failed to find target a. The problem can be easily understood by running docker compose config b, which will show that service a does not exist in the configuration when you specify b explicitly.
There is an ugly workaround, which is using a depends_on for creating a runtime dependency, which will force a into the config when b is specified explicitly. This will let me do docker compose run --build b, but it will startup both service b and a, and I although I think it is reasonable to want b, I usually do not want a. One can start to play with more workarounds, like adding a parallel tree of build dependencies with a no-op entrypoint, but everything starts to get cumbersome and you start to hit other bugs.
Everything would work out of the box if docker compose config b brought a into the config, but somehow managed to mark it as not to start.
Going further down, once this is fixed, the build time dependency graph should also be exposed to docker compose watch, but I guess that goes as a different bug later.
The text was updated successfully, but these errors were encountered:
Description
The new service: directive for additional_contexts almost fulfills the dream of letting docker/docker-compose become highly usable in a monorepo scenario, where images depend on other images built on demand in the same repository. See https://stackoverflow.com/a/79487072/95653 for an 8-year-old question in that direction finally getting an answer.
However, the build time dependency created by the additional context is not represented anywhere, and as a result, most commands break. Please review the example below, which is adapted from the aforementioned Stack Overflow answer.
If you run
docker compose build
, everything works as expected. However, if I dodocker compose build b
, I getfailed to find target a
. The problem can be easily understood by runningdocker compose config b
, which will show that service a does not exist in the configuration when you specify b explicitly.There is an ugly workaround, which is using a depends_on for creating a runtime dependency, which will force a into the config when b is specified explicitly. This will let me do
docker compose run --build b
, but it will startup both service b and a, and I although I think it is reasonable to want b, I usually do not want a. One can start to play with more workarounds, like adding a parallel tree of build dependencies with a no-op entrypoint, but everything starts to get cumbersome and you start to hit other bugs.Everything would work out of the box if
docker compose config b
brought a into the config, but somehow managed to mark it as not to start.Going further down, once this is fixed, the build time dependency graph should also be exposed to docker compose watch, but I guess that goes as a different bug later.
The text was updated successfully, but these errors were encountered: