https://pulumi.com logo
Join Slack
Powered by
I have an interesting usecase / thought experiment...
# general
f
I have an interesting usecase / thought experiment - When someone makes a pull request to our codebase, I (think I) want to (for each stack): 1. Preview without refreshing (to see if the code changes would impact an environment, but without taking into account any drift) a. If there would be no changes, stop here - we'd exclude this stack during deployment via the same mechanism 2. Refresh, but to a "temporary" or "ephemeral" "copy" of the stack. Not to the primary copy, because other PR's might need to do step 1 (again, without drift) 3. Preview against the copy, writing the results to a comment on the PR The goal is to be able to write features, disabled via feature flags, and not need to do drift adoption in any stacks. Then, if we are going to deploy something new to some number of stacks, we would only need to do drift adoption in those impacted stacks
Thinking about this more, there might be a way to get away with it without copying the state, 1. preview without refreshing, make PR comments 2. 
pulumi refresh --preview-only
and make a second PR comment to show drift This could be confusing though; say someone adds a resource tag via the cloud console and we update the code to match - this should preview cleanly, but we would see a comment for adding the tag (from code) and a comment for deleting the tag (from the drift). Using 
pulumi stack export
and 
pulumi login file://$(mktemp)
could be more complex but is probably more robust
I wish there was a 
pulumi preview --refresh=preview-only
to preview against the most up-to-date model of the cloud, without modifying the statefile
Gemini is telling me 
pulumi preview --refresh
already doesn't edit the statefile? Is that true? I don't trust it 😅
g
That’s correct. 
pulumi preview
doesn’t modify state. It’s equivalent to running a 
pulumi up --refresh
and then declining the update.
👀 1
2 Views
Open in Slack
PreviousNext
Powered by