I'd love to hear others thoughts around the use of

pulumi refresh

, not necessarily tied directly to Automation API, but it is the context that we're currently working in. I've raised an issue on the .NET repo (https://github.com/pulumi/pulumi-dotnet/issues/244) now that the

--preview-only

flag is available via the CLI, but not yet for .NET. It's raised some questions internally in my workplace as to how

pulumi refresh

should fit into the workflow of stack updates. It's not super clear to us how best to manage state drift (auto apply, expect no changes etc), so if anyone else has come across something similar, I'd be super keen to hear how you are incorporating it.

Our incorporation of it is almost strictly for manual operations, where the drift is required and the refresh helps us get back on track with the deployment pipeline. The cases where refresh has been integrated has smells. For example, one is refreshing to get rid of stale references in a WAF configuration that will cause the deployment to fail unless it's refreshed. This is bandaiding a design problem. So I suppose my question is, have you run into a case where you proactively need the refresh, or have you been refreshing as a "precaution?"

Ha not a problem - should have put some of that info here probably! We haven't yet incorporated it into our processes, so we can't say that we've proactively needed the refresh, nor have we been doing it as a precaution. We certainly won't be using it to bandaid design problems, although I do know in Azure land it can be funny with VNets/subnets - so I better not speak too soon.. I was not aware a destroy works off state, something to keep in mind. Although, generally speaking, we aren't expecting there to be massive amounts of drift in various resources. Mainly we use Automation API to manage deployments of some of our services, including container versions/traffic weighting. So our main use case is to capture things like someone manually changing this in the portal, then those changes not being fed back into Pulumi. Obviously, we want to minimise these manual changes, but there are rare times where it cannot be helped, so maybe that leads us down the path of only requiring a refresh in one-off occurrences, but we can't/don't expect everyone to have that front of mind and roll those drifts back into Pulumi.

Yeah, that all makes these. I expected to lean on refresh more than I ever have. It's been more of the tool to help me get the train back on the rails during rougher transitions.