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

Your code isn't run during

pulumi destroy

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.

isDryRun is correct for this

@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.

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.

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.

gotcha that makes sense. thanks!

@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.