I’m having trouble getting a multi-arch Docker image built; if I pass multiple values to

build_platform

, my local Docker (Docker Desktop, Mac OS) complains that the docker driver doesn’t support multiple platforms. Running manually in the sandbox I can fix it by using

docker buildx build

instead of the

docker build

generated by pants. No other incantation of

docker buildx use

or setting up drivers seems to work. As a workaround, I’ve been playing with just generating single-platform targets, and then I can massage the manifest with an

adhoc_tool

target; this works but I don’t know whether I’m walking into a maintenance trap long term. Example BUILD file:

for platform in ["amd64", "arm64"]:
    docker_image(
        name=f"runtime_{platform}",
        repository=IMAGE_REPO_NAME,
        target_stage="runtime",
        build_platform=[
            f"linux/{platform}"
        ],
        image_tags=[
            f"latest_{platform}",
        ],
        dependencies=[
            ":release"
        ],
    )

    docker_image(
        name=f"debug_{platform}",
        repository=IMAGE_REPO_NAME,
        target_stage="debug",
        build_platform=[
            f"linux/{platform}"
        ],
        image_tags=[
            f"debug_{platform}",
        ],
        dependencies=[
            ":release"
        ],
    )

I’m struggling with a similar question about dependency inference for a Go binary, if I’m running on ARM, and have a

go_binary

target that gets inferred in my Docker container, since the build happens locally, when I build an x86 container the binary that gets placed by pants is invalid. Would it be insane/possible to do the same target generation as above for my

go_binary

and then do something like:

COPY src.go.cmd.mytool/bin_${BUILDARCH} /bin/mytool

in the Dockerfile? I would generate each

go_binary

target with a local environment that sets the

GOARCH

so

package

cross-compiles the binary for the correct platform.

long term (not that far away) there’s a new

[docker].use_buildx

option that’ll use

docker buildx build

for you 😉 coming in 2.19.0 (it will be in the next rc for 2.19 if you want to try it out early, please do 😉 to report any issue so we get a chance to fix them before the final release) https://github.com/pantsbuild/pants/pull/20154

Oh, interesting! Happy to try out the 2.19 RC, this is a greenfield project that isn’t in production anyways yet so no concerns using a prerelease. Any thoughts on my parameterization of

go_binary

targets?

Cool. Regarding go, I don’t know much about the go backend and what cross compile support there may be. I notice there are fields for compiler flags and stuff but 🤷 I hope someone else in the community who use the go backend may have a better answer.. 🙂

Thank you for the heads up on the buildx feature 🙂

you’re welcome 🙂

@curved-television-6568 I saw in the PR diff above that we are using env var

BUILDX_BUILDER

to specify the docker builder name. I recommend that this could also be abstracted as a setting

[docker].builder

and added to

--builder

CLI arg for command

docker buildx build

or

docker build