This message was deleted.

I tried always returning 

{ changes: true }

 from 

diff

, but that didn’t work.

In order to _re_create the resource, you should also return

deleteBeforeReplace: true

as your

diff()

result. As the name implies,

delete()

will be called, followed by

create()

for your dynamic resource.

I don't need it to be deleted before its replaced. It's just that if I run

pulumi up

and the arguments didn't change, Pulumi doesn't even call

diff

. I ended up fixing this by instead implementing it how

docker.Image

works which uploads to the registry in the constructor when

pulumi.runtime.isDryRun()

is

false

You could trick the change detection by introducing a change token as one of the inputs to the dynamic provider. The change token could be a timestamp or some other value that you control how it is set. By changing it, you could cause the diff to be invoked I think.

Or you could make the name of the resource different each time? Add a new suffix or similar? Since Pulumi manages a desired state, it doesn't really map to simple imperative operations too well. If you want a new cloud resource each time, you probably want to create a new Pulumi resource too: an array, instead of a single object.

Yeah, I thought of adding the git commit sha to the deployment metadata, or I could use a hash of the files being uploaded... As for the imperative operations dichotomy, this is something I explored a bit over a year ago with Docker and it does seem Pulumi is ok with it. Think of the

docker.Image

resource. Every time

pulumi up

is run it pushed up a new image, which is immutable, even thought there's only 1 resource, not an array. Also, the images are never deleted event though, for example, `gcp.storage.BucketObject`s do get deleted when the resource is destroyed