https://pulumi.com logo
Join Slack
Powered by
Hello, how can I generate a diff file between the ...
# general
l
Hello, how can I generate a diff file between the actual state and the pulumi state? 
pulumi refresh --diff --non-interactive
complains with:
Copy code
error: --yes must be passed in to proceed when running in non-interactive mode
I'd rather pass a 
--no
if it was available
b
I don't think there is a way to 
pulumi refresh
and not update your pulumi state unless there are no changes or unless you do 
--expect-no-changes
but I don't think that is what you are looking for. Is 
pulumi preview
not what you are looking for? To clarify, you don't want to see the difference between your Pulumi Code & Actual State but rather, your Pulumi State & Actual State?
Or maybe the combination of 
--diff --expect-no-changes
with 
pulumi refresh
will give you what you are looking for? Since it will error out if there are changes so won't change anything, and the 
--diff
hopefully gives you the rich diff you're looking for
l
yes, I'd like to see the difference between my Pulumi State & Actual State?
Copy code
filip@FZYZNIEWT15G:~/git/bitbucket.org/taxamo/taxamo-devops/infrastructure/opsgenie$ pulumi refresh --expect-no-changes --yes < /dev/null
[...]
Resources:
    ~ 1 updated
    52 unchanged
Duration: 2s
error: error: no changes were expected but changes occurred
--expect-no-changes does not seem to prevent an update
b
I think doing a 
pulumi preview
having made no changes to your code will give you your difference between Pulumi State & Actual State
If you have made changes to your code since your last 
pulumi up
, than you'll be seeing the difference between your Pulumi Code & Actual State, which would be a superset of the changes between your Pulumi State & Actual State
so it's semantics
l
@bored-oyster-3147 are you sure? I thought that preview does not do refresh by default per https://github.com/pulumi/pulumi/issues/2247
b
Ah well you are correct. It doesn't appear that there is a way to get just a preview of your 
pulumi refresh
via the CLI.
Out of curiosity, why would that be useful? In what scenario would you want to 
pulumi refresh --preview
and then decide not to go forward with a 
pulumi refresh
?
l
I would like continuous deployment to abort if 
pulumi refresh --diff
is not empty
and to address that, the operator needs to do a refresh in a separate pipeline, where they are presented with a refresh diff first and then they get to decide if to apply it
@bored-oyster-3147 do you think this could be more easily achieved with https://www.pulumi.com/docs/guides/automation-api/ ?
b
So by aborting what scenario are you trying to prevent?
I don't think Automation API will help you here because under-the-hood it is still using the CLI so will still largely have the same behavior.
l
@bored-oyster-3147 wait, are you trying to tell me that Automation API function calls will be expecting a TTY with user input on it?
b
no they use 
--non-interactive
so it will always go right through without user input, but there still won't be a way to prevent the 
pulumi refresh
if there is 
--diff
results.
l

https://www.youtube.com/embed/jJOwdrTA8Gw?start=317&amp;end=319&amp;autoplay=true▾

b
What I'd like to know though is - what are you trying to prevent by aborting on 
pulumi refresh
if there is a diff? Why would you not want your pulumi state to be a reflection of reality? Are you trying to prevent certain resources from being created or destroyed? I'm trying to understand better to see if there is another solution.
l
so it's not about the refresh itself - if it is aborted, the operator would need to trigger a refresh anyway (that would be the expected thing to do in this case)
but I would like continuous deployment to apply only changes resulting from code changes, not from out-of-band actual state changes
so if there is an out-of-band actual change, it should be addressed before trying to deploy a code change
addressed = actual/state diff examined and then refreshed
b
Well then I think 
--expect-no-changes
would work for you. Because it would do the refresh that your operator was going to do anyway, and then it would fail your continuous deployment if there were changes so that you could address it
l
yeah, but then the CD pipeline fails AND makes changes to the state
I find it awkward
it should try failing before making any changes if possible
b
but if you have the 
--diff
flag then you'll be able to see your rich diff right in your CD pipeline and your operator can examine it there.
l
yes, but then a simple rerun of the pipeline will succeed
so it would not be idempotent
it's not a disaster, but leaves a bad taste IMO
for CI/CD I'd like all checks to be performed read only
b
Obviously a 
pulumi refresh --preview
isn't currently possible so I am just making suggestions. There is nothing I can do about 
pulumi refresh --preview
not being currently possible.
l
in fact, I plan not to give write access to pulumi state to the role used for CI/CD previews
well I have an idea, but my teeth hurt about it 😉
🔑 1
b
You could hack it and export your current state and import it into a new local temporary stack and then refresh that instead lol. Ofc I wouldn't feel good about that either
l
Copy code
$ cat refresh-preview.sh
#!/bin/bash

# Workaround for <https://github.com/pulumi/pulumi/issues/1666>
# to be able to say 'no' non-interactively
nope() {
  echo n | script -qfec "$(printf "%q " "$@")" /dev/null | tr -d '\r'
}

OUT="$(nope pulumi refresh --diff --color=never)"

if egrep -qx ' *~ [0-9]+ to update' <<< "$OUT"
then
  echo "dirty state!"
else
  echo "clean state!"
fi
$ bash refresh-preview.sh
dirty state!
$
b
hmmm this will still update your state though, right?
I'm not familiar with the 
nope
command
l
no, it's interactive and I say 'n' (echo n)
nope is defined in the script
b
oh lol duh
man I hate bash its such a pain to read lol. ok cool well if it works for you until its supported then hell yea!
l
I'll need a shower after committing this
b
because you're in a 
dirty state!
l
😄
indeed
217 Views
Open in Slack
PreviousNext
Powered by