Greetings! I recently gave a try to the new docker-build provider (https://www.pulumi.com/registry/packages/docker-build/) to replace the former Image build with the docker provider (https://www.pulumi.com/registry/packages/docker/api-docs/image/). I’m a bit set back; while trying to build images based on local images (eg

whatever/something:idk

),

pulumi up

fails and raises the issue that I’m not allowed to pull (from

<http://docker.io/whatever/something:idk|docker.io/whatever/something:idk>

). I guess that comes from the change of builder (docker-build to buildx), but I have no idea how to correct that. If anyone has any clue on how to solve that, I’m game! 🙏

hi @rapid-advantage-25766 - the docker-build provider essentially just exposes

docker buildx build

. it would be helpful to first replicate what you’re trying to do using the CLI, to rule out any pulumi-specific behavior. there are a number of things that could be causing it to try pulling the image, e.g. if you’re trying to use a local image as a base image with a platform mismatch. it would also be helpful to see the actual image resource you’re working with.

Sure thing; I’ll first try and replicate it using

docker buildx build

. I don’t think the image itself will reveal much; it’s basically an image built from scratch, with a binary built with go that awaits a SIGINT. The smallest image that does nothing until it’s killed, if I dare say. Looks like this:

FROM golang:1.21-alpine3.18 AS go-builder
COPY resources/wait4sigint.go /wait4sigint.go
ARG GOOS
ARG GOARCH
RUN GOOS="${GOOS}" GOARCH="${GOARCH}" go build -v -o /wait4sigint /wait4sigint.go

FROM scratch
COPY --from=go-builder wait4sigint /
ENTRYPOINT ["/wait4sigint"]

And the go program itself:

package main // wait4sigint

import (
	"fmt"
	"os"
	"os/signal"
	"syscall"
)

func wait4sigint() {
	done := make(chan os.Signal, 1)
	signal.Notify(done, syscall.SIGINT, syscall.SIGTERM)
	fmt.Println("block until SIGINT")
	<-done
}

func main() {
	wait4sigint()
}

I’ll provide a minimalist repo to replicate if I can’t solve it by myself thanks to your hints, but hopefully that won’t be necessary 💪

not rude at all 🙂 what does your pulumi code look like? and are you perhaps on an m1 mac building for x86 or something like that?

Sorry for the late answer, I’ve been away for a couple weeks. It turns out that my experiment was going against buildx’s philosophy to make a build environment agnostic and replicable anywhere. Therefore, using local images isn’t advised, and in the case of multi-platform images, it isn’t supported at all depending on the builder instance backing driver (be it docker-container or kubernetes). I was led on the right track by this issue https://github.com/docker/buildx/issues/301. It was indeed not a Pulumi-related issue at all. I will likely walk-around it by deploying and using a docker registry in my stack.

glad to hear you got to the bottom of it!