No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Hello Everyone. It seems there is no import option for `pulumi.docker.image`! So am I forced to build the image everytime that I run pulumi up?
This is a core part of any reasonable pipeline not to build projects that haven't changed. It is frustrating that this option doesn't exist in pulumi.

You can use the docker-build provider, which handles this better.

However, if you prefer the older docker provider: if you don't want the image built, what is the reason to have an Image resource? Would you be better off with a RemoteImage, which is an Image that has been uploaded somewhere (e.g. by a previous step in your pipeline)?

Thx <@U012UJTT55M> for taking the time to answer my question. I do want to build the image when there is a change to the project (isn't it the default behaviour of all reasonable pipelines?). So that's a step in my pulumi code. But I cant simply say if there wasn't any project change just ignore the step cause pulumi would go and delete the image that way!

So you may want to try docker-build, but in general, my personal recommendation is to not use your deployment code to build a build output. That's just conflating disparate concerns.

If you didn't change anything, the build step can tell that. The deployment step is either kicked off or not kicked off. It shouldn't have to figure out if things need to be deployed: if they don't need to be deployed, it shouldn't be invoked.

It _can_ do it, of course. The docker-build provider has a reasonable stab at it. But it shouldn't _have_ to do it.

Deployment changes should be based on drift detection: is what-is-deployed different to the deployment code (Pulumi code)? But buildnig a Docker image isn't checking either of those things.. it's very different.

Really, it has to build all the image layers and check that they're all deployed to the OCI/docker registry. It's just not the same paradigm as state&lt;-&gt;cloud checking.

You are right. The essence of image creation is different from resource creation. So I will move that step to the pipeline. Thx for the help.