Buildx caching in CI not working without load: true

[mikepurvis]

This is a bit of an odd one but I started my project with a single large Dockerfile of about twenty stages + a heavily matrixed bake config. The early "deps" stage of the build was installing 6GB+ worth of dependencies, so I set it up to export a generated "preinstall" Dockerfile that acts as a kind of lockfile for some cache layers. Basically the generated Dockerfile looks like this:

FROM ubuntu:noble AS preinstall

RUN apt-get update && apt-get install -y a=1 b=2 c=3 && apt-mark auto a b c && rm -rf /var/cache/apt/* /var/lib/apt/lists/*

RUN apt-get update && apt-get install -y d=1 e=2 f=3 && apt-mark auto d e f && rm -rf /var/cache/apt/* /var/lib/apt/lists/*

...

And then the main Dockerfile is:

FROM preinstall AS build
RUN buildy build build

FROM preinstall AS image
COPY --from=build the/things

I don't want to actually push the preinstall image anywhere, so I hoped I could just wire together the targets at the bake file level, basically just doing contexts = { preinstall = "target:preinstall" }. Should be a dream for caching, right, with everything super explicit like that?

All this works great on my workstation, but the issue I'm having on CI is that buildx seems to be unwilling to recognize that those preinstall layers are available in cache. I really don't want to push these to their own layer on the registry and would rather just use cache-to and cache-from.

What seems to work is if, in my Actions workflow, I do this:

      - name: bake apt-preinstall
        uses: docker/bake-action@v6
        with:
          source: .
          targets: preinstall
          load: true

      - name: bake image
        uses: docker/bake-action@v6
        with:
          source: .
          targets: image

This causes the preinstall layers to get loaded into the buildx instance and then the main bake is able to recognize and use them. Things I tried that did not work:

• Removing load: true. Without this, the apt-preinstall step goes by so fast that I suspect buildx realises it doesn't actually have to do any work and doesn't even download the layers. But I'd like a way to force it to make the download without also wasting time making tarballs to transfer into the runner's docker instance.
• Baking only the main image. When baking only the main image, it can't seem to follow the context mapping logic for the purposes of looking for cache data, and instead rebuilds everything.
• A single bake with both targets. Same as above, no matter what I put in the cache-from block, it will insist on rebuilding the preinstall layers.

What did also work was putting a tiny cache-busting shim layer at the bottom of the preinstall dockerfile. Building this in the preinstall Actions step forces it to actually perform the download and then the cache layers are present in buildx and everything else goes as expected. This feels like a really unfortunate hack, though.

Obviously the ideal would be if the build backend was able to directly pull cached layers for targets wired together at the bakefile level, but failing that, it would also be great if there was an option in docker/bake-action that was was like push and load but instead of actually copying anything, it would just force the builder to fully realise the targets into its own layer storage.

Does that make sense? Is there some other path I'm not seeing here? Would it be helpful to try to prepare a MWE that demonstrates the issue or is this a manifestation of something that's already well known and understood?