Is there a way to tell Pulumi to not delete a reso...
# general
w
Is there a way to tell Pulumi to not delete a resource once it's been create, i.e. drop it from state if it should delete. The use case being to create a blob in Azure with a name that includes the build reference, then when the next build runs, just upload the next, and keep the previous?
b
You can remote it from state for sure Pulumi state rm <urn>
You’d need to be careful nothing references it though as that may break the dependencies
w
I'm trying to do it in a more "Automated" way, so that wouldn't really work. example: https://github.com/pulumi/examples/blob/master/azure-cs-functions/FunctionsStack.cs#L52 This blob is used as the source for the WebApp code. When a new build happens, the blob url doesn't change, therefore you don't get an update to the function. What I need is a way to update that blob url on line 95 so that it points to a new blob, without deleting the old blob. The "without deleting" is important as there's no guarantee that existing functions have picked up the new URL, so both need exist until the updates has fully propogated, which I don't believe we can know.
right now, I'm solving it by adding the current datetime for the blob name, meaning that it deletes and recreates it each time.
l
This sounds like it might do that... however I've never used it myself so I'm not sure exactly how it works. This may be an accidental red herring, I'm just passing it along in case you wish to try it out: https://www.pulumi.com/docs/intro/concepts/resources/#protect
w
Protect wouldn't really do that, as it stops you from accidentally deleting a resource by stopping the deployment if it detects a delete.
👍 1
b
Since pulumi is just code, what about making a copy of the blob if exists.
Or if you don't really need the blob except in rare cases, can you not enable versioning on the bucket making any deletes "soft" deletes that can be recovered.
w
All good points, but unless Pulumi thinks it's a new resource, it won't change the contents of the blob. So no amount of versioning etc. will fix that. Building it as a custom http request may work, but that feels very hacky.