https://pulumi.com logo
Title
l

little-soccer-5693

11/15/2022, 12:18 AM
within a pulumi program is there a way to differentiate between a "pulumi up" from a "pulumi destroy" ? i see there is a pulumi.Context.DryRun()* to determine whether it is a preview or not, but it isn't clear how to determine what operation is being run. * https://github.com/pulumi/pulumi/blob/master/sdk/go/pulumi/context.go#L220
l

little-cartoon-10569

11/15/2022, 12:30 AM
Your code isn't run during
pulumi destroy
b

bumpy-ice-21024

11/15/2022, 12:49 AM
Was actually curious myself how to differentiate between preview and up. Only thing I could think of is passing the action in via a config var which seems kind of redundant.
l

little-cartoon-10569

11/15/2022, 12:56 AM
isDryRun is correct for this
b

bumpy-grass-54508

11/15/2022, 6:13 AM
@little-cartoon-10569 I just saw a message on a similar topic from @echoing-dinner-19531 here: https://pulumi-community.slack.com/archives/C84L4E3N1/p1668437537579989?thread_ts=1668436417.259309&cid=C84L4E3N1 asking both of you - is it ok to lean on
destroy
not running the user program? if that changes in the future would it be mandatory? I am building some services that make heavy use of the Automation API and currently getting away with not passing any program to the workspace/stack when destroying.
l

little-cartoon-10569

11/15/2022, 6:20 AM
I'm not privy to Pulumi design decisions, sorry. I can't see any advantage for Pulumi to run our code on destroy: everything it needs to destroy a stack is in state. I would say it is safe to rely on this, but that's just a personal opinion.
e

echoing-dinner-19531

11/15/2022, 9:22 AM
I can't see any advantage for Pulumi to run our code on destroy: everything it needs to destroy a stack is in state.
That is true today, but there are some features people ask for (like delete hooks) which wouldn't be able to be stored fully in state and so we would have to run the program to get hold of them. It's likely that we would do a best effort to only run the program iff we saw the state had reference to new features that needed it, so if you weren't using those features you'd be able to continue running destroy without the program.
b

bumpy-grass-54508

11/15/2022, 1:35 PM
gotcha that makes sense. thanks!
l

little-soccer-5693

11/15/2022, 5:36 PM
@little-cartoon-10569 thank you for correcting my mental model of destroy. i had previously assumed that pulumi destroy worked by computing an inversion of the user's program, but in hindsight just leveraging the stack's persisted state is more obvious.