Skip to content

Usage of additional_contexts with the service: directive should imply build time dependencies #12783

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
davireis opened this issue Apr 27, 2025 · 1 comment · May be fixed by #12785
Open
Labels

Comments

@davireis
Copy link

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.

  a:
     image: service_a
     build: 
       dockerfile_inline: "FROM alpine"
  b:
     image: service_b
     build:
       args:
         BASE_IMAGE: service_a
       dockerfile_inline: "FROM service_a"
       additional_contexts:
         # instructs resolving `FROM service_a` to "service a" image
         service_a: "service:a"

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.

@ndeloof
Copy link
Contributor

ndeloof commented Apr 28, 2025

requalified as a bug, my earlier fix for this was incomplete

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants