Naming consistency for stages common to multiple targets

[mikepurvis]

Description

I have a bakefile that builds three similar production containers, call them foo, bar, baz. Building each of these involves calling the same 10+ stage Dockerfile with different parameters. In addition to that, each of the containers has some additional offshoot targets, like foo-test, foo-dev, and foo-logs (which uses a type=local output to exfiltrate detailed build exhaust for archival). So my default bake is like:

group "default" {
  targets = [
    "foo", "foo-test", "foo-dev", "foo-logs",
    "bar", "bar-test", ...
  ] 
}

My issue is that while this is running locally, the stages that are "common" to the foo family of targets seem to be able to be attributed to any of them in the build spool— it's just random. This makes it confusing to know if installing the base deps installation is truly a special part of foo-test, or if it's really part of foo, and only being labeled as foo-test because foo-test extended all or most of foo.

My proposal would be that there should be some deterministic policy for how buildkit labels stages common to multiple targets, with the simplest being to just always choose the name that is the shortest in number of characters, but something more enlightened might the first one that is specified in the bake list (if that ordering information is available to buildx).

I'm on buildx 0.25.0 and docker 28.3.2

[tonistiigi]

If I understand correctly, you're referring to the progress stream and specifically the stage names shown at the beginning of each step in the build output.

If that's the case, I'm not sure why you'd be seeing the same steps attributed to different targets arbitrarily. If multiple targets share a common base stage (via FROM), the progress for that stage should be logged consistently under the shared stage's name, not under one of the consumers. If you're seeing duplicate commands across different stage names, it might be because those commands exist in multiple separate stages, not a single shared one.

In that case, wouldn’t it make more sense to refactor the Dockerfile to remove duplication, so the shared logic resides in a common base stage? That way, attribution and caching would both be cleaner and more predictable.

[mikepurvis]

Ah, sorry for the confusion. The issue is not with the Dockerfile stages, but rather the Bakefile target names. Here's a trivial example to hopefully illustrate, with this Dockerfile:

FROM alpine:latest AS build
RUN echo "building" && sleep 2

FROM build AS test
RUN echo "testing" && sleep 2

And this bake config:

target "app-build" {
  dockerfile = "Dockerfile"
  target = "build"
}

target "app-test" {
  dockerfile = "Dockerfile"
  target = "test"
}

When I bake both targets, on the marked line the "build" stage is part of both app-build and app-test, but I'd like this to be attributed to the app-build target. More that that, I suppose I'd like it to be deterministic, as right now it's not— if I rerun this a bunch of time without cache, it'll flip-flop, potentially causing confusion to users and log analysis tools:

$ docker bake app-build app-test --progress plain
<snip>
#5 [app-build build 1/2] FROM docker.io/library/alpine:latest@sha256:8a1f59ffb675680d47db6337b49d22281a139e9d709335b492be023728e11715
#5 CACHED

#6 [app-test build 2/2] RUN echo "building" && sleep 2    <---------------------------------------------
#6 0.313 building
#6 DONE 2.4s

#7 [app-build] exporting to image
#7 exporting layers 0.1s done
#7 writing image sha256:42ae59418fcd4c3b6242940de7103765e2fa58848edfce3b0bc43ef690583018 done
#7 DONE 0.1s

#8 [app-test test 1/1] RUN echo "testing" && sleep 2
#8 0.418 testing
#8 DONE 2.5s

#9 [app-test] exporting to image
#9 exporting layers 0.1s done
#9 writing image sha256:cc631382cd72bb9885a1177ea570852086465b9a4f0a861e6cddcbe1973c7e86 done
#9 DONE 0.1s

[tonistiigi]

I see. I'm not sure how this could be improved as bake layer does not know how the different builds will share some of the steps. The builds are started in parallel and progress comes as they run. Can't do things like pick the shortest or alphabetical as if the progress from other build comes first, it has already been written out (especially in plain mode, in tty mode could theoretically switch a step's name).

[mikepurvis]

That’s reasonable, if it simply can’t be done. Admittedly I have very little insight into how the build is chunked up into stages and actually dispatched to the builder(s). And for what it’s worth, nix actually has a similar issue with attribution when chasing multiple targets in overlapping DAGs.

If there’s some way that each stage could be pre-annotated with the preferred target to label it using, then that name could be used even if a different target’s worker “gets there” first.

If you don’t think it’s possible though, or the effort outweighs the value, feel free to close the issue.