This message was deleted.

I don't know what S3 caching is, but if the args aren't exposed via the Docker provider, then yes, you should use your own scripts to do this. My preference is to not build Docker images from Pulumi. Entangling your build and deployments like this causes problems. Maybe the code and the tools can handle it fine, but different developers will have different understandings and confusion will result. Treat building as building, and deploying as deploying.

Yeah totally agree, so is there a Pulumi pattern to perform the

docker push

operations such that it will track the Image as a asset (check for updates on preview etc) ?

The opposite: use RemoteImage as the resource, and it detects changes after your build pipeline pushes.

Yes, you need multiple stages. Your infrastructure should be grouped into projects based on deployment frequency. If you intend to create a new registry for every image push, then you put your registry and your build-and-push code into one project. But since no one does that, you put your registry-creating code into your infrastructure-that-must-exist-in-order-to-build project, and you put your pull-image-and-start-container code into your app-deployment project.

Totally agree with that design at scale. And its a really fair point to consider this a point to break up the infra into stacks/projects. It does seem far heavier weight compare to just supporting import+push I guess? I guess I should say: I feel like I shouldn't need a new pulumi stack to run

docker push

? I mean I could just be wrong though

You definitely don't need it. It will work fine via the Docker provider, or via pulumi.Command. This is all just my preference 🙂 I don't ask Pulumi to run

npm publish

, and

docker push

is at exactly the same place in the SDLC, so.. this is how I do it.

Thanks! Makes sense, I guess some resouces are easier to import from like FileAssets vs other things like docker images so it can be deceptive for which inputs can easily be treated like a external asset.

Yes, and it will work both ways. I have just found that there's less confusion and fewer people stepping on other people's toes when the separation between build and deploy happens after

docker push

, rather than before.