Can't schedule build of dependent images

[ndeloof]

This issue was initially reported as docker/compose#8538

build.Options matching service definitions in a compose file are set with independent context paths and image tag. If a the service is set by Dockerfile to declare FROM <another_service>, buildkit should know about this base image being part of the enclosing build request, and manage this implicit dependency.

[tonistiigi]

There's been some discussion about providing overrides in docker/buildx#447 (comment) . Notice that these would be configured by the user. The build requests are all independent as far as buildkit is concerned. You can't set these overrides automatically as well as then you would have a cross-dependency.

If compose chooses to schedule some requests sequentially and use image store to access local images for base images that is up to compose to decide.

[ndeloof]

a "client-side" solution would require client (compose, or bake) to parse the Dockerfiles, including support for FROM used by multi-stage and selected target to only consider the relevant ones, with support for build args (sometime used to customize FROM instruction), not to mention extension on dockerfile syntax that may appear and have some impact...
so, basically, you're asking the client to replicate a significant part of the builder!

[tonistiigi]

a "client-side" solution would require client

You are asking two independent builds to synchronize with themselves without any constraints given. As I wrote, doing this automatically isn't even theoretically possible because of the infinite dependency loop it creates. The decision for compose authors would be if this pattern should be forbidden or if it is important enough for the compose to not trigger all the requests together but run them sequentially(eg. how the old builder did). If you really want to detect the dependency chains buildkit could possibly provide you that info(in some cases it may not ever be possible without triggering builds, eg. dockerfile cross-linking etc). I think that part should already be possible with #2311

[ndeloof]

I don't understand why this would be "even theoretically possible" as I have no idea about buildkit internals, but sounds clear to me you don't see a simple way to address this need, so will need to make compose build just plain sequential and drop potential benefits of using buildkit for better build concurency.

[tonistiigi]

What I don't see possible is the automatic aspect of it. Eg. look at the syntax in docker/buildx#447 (comment) . If these rules would be added automatically then it says "build A into foo, if you see bar then replace it with the result of B", and "build B into bar, if you see foo then replace it with the result of A". The API would not even allow you to make such requests as to build A you would need result of B first and you can get reference for it because it depends on A. For a practical case, the user would have no problem of saying which replacement they want and what they don't need. Eg. with syntax similar to described in that comment or maybe for compose you can repurpose depends_on for it somehow.

Lets continue to track it in docker/buildx#447 . If you want buildkit to export more info from a build for some client side implementation then create a separate issue for that in here.

[ndeloof]

reading docker/buildx#447 "only true for docker daemon driver" this means we are stuck because buildkit was designed too generic :'(

docker/buildx#447 is indeed exactly what a compose user would expect build to manage. I hardly can imagine how to manage such things client-side.

on compose v2 it seems we don't have any better choice but build image sequentialy, like docker-compose did with classic builder

[tonistiigi]

like docker-compose did with classic builder

That's not true actually. --parallel is older than buildkit docker/compose#6115 . Nobody complaining in that issue, I guess because this is hardly a valid use case. If you are building different variants of same software you should use same dockerfile, otherwise, you shouldn't inherit from your service image.

[ndeloof]

you shouldn't inherit from your service image

for some reason I never fully understood, Dockerfile composition like moby/moby#735 never have been approved, which would be a simple and efficient way for services to define a common dockerfile parent and avoid such de facto feature in docker-compose to support build dependencies