I have a

docker_image

that I've configured to successfully build an artifact (specifically CoreDNS with custom plugins). BUILD:

docker_image(
    name="build-coredns",
    output={"type": "local,dest=."},
    target_stage="artifact",
)

Dockerfile:

FROM golang:1.25 AS builder

WORKDIR /build

RUN wget <https://github.com/coredns/coredns/archive/refs/tags/v1.14.2.tar.gz> -O core-dns.tgz && \
    tar -xzvf './core-dns.tgz' --strip-components 1 -C /build
RUN GOFLAGS='-buildvcs=false' make

FROM scratch AS artifact
COPY --from=builder /build/coredns /coredns

And the output in the sandbox:

riebecj@Casey-PC:/tmp/pants-sandbox-76AxD7$ ls -latr
total 71656
-rwxr-xr-x  1 riebecj riebecj 73253048 Apr 14 17:39 coredns
drwxrwxrwt 44 root    root      102400 Apr 14 17:58 ..
drwxr-xr-x  2 riebecj riebecj     4096 Apr 14 17:58 backplane-dns
-rwxr-xr-x  1 riebecj riebecj      314 Apr 14 17:58 __run.sh
drwxr-xr-x  3 riebecj riebecj     4096 Apr 14 17:58 .

So, it was able to use buildx to output the built binary, but I'm not sure of any mechanism I can use to extract it from the sandbox and use it in subsequent targets. Ideas?

Something like this might work:

shell_command(
      name="build-coredns",                                                                                                         
      execution_dependencies=[":dockerfile"],
      command="docker buildx build --output type=local,dest=. --target artifact -f Dockerfile .",                                   
      output_files=["coredns"],                                                                                                   
      tools=["docker"],
  )

But that is pretty hacky and isn't re-using most of what Pants knows about docker. Is the use case cross-compiling, or something else?

Building CoreDNS with some external plugins enabled. They're out-of-tree, so you have to either wrap the build with your own go package, or update the

plugins.cfg

and build from source. I opted to just build from source, but I wanted to do it inside a container for ease of use. I was hoping to use the

docker_image

target to make use of layer caching when building, but the output isn't captured as a digest to be used in subsequent targets. I'll probably end up using the

shell_command

, I was just hoping there was some magic I could do to get that output cached in digest. Maybe, when I'm done with my current project, I can build that as a feature for the

docker_image

target.

Yeah this seems reasonable in principle. I'm not sure exactly how all of the adhoc/docker/environment stuff should compose together

@happy-kitchen-89482 Submitted a pull request to add support for this.