Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide option to not fail a destroy when the stack doesn't exist #1001

Open
passcod opened this issue Jul 31, 2023 · 4 comments
Open

Provide option to not fail a destroy when the stack doesn't exist #1001

passcod opened this issue Jul 31, 2023 · 4 comments
Labels
kind/enhancement Improvements or new features

Comments

@passcod
Copy link

passcod commented Jul 31, 2023

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

We have a workflow that destroys a Pulumi stack when a PR is closed. However, not all PRs get deployed. For those, the destroy workflow fails. While not critical, this is still annoying and means if there's an actual error, it likely won't be caught as people are effectively trained to ignore errors on this workflow.

We'd like to have an option, eg ignore-missing-stack: boolean that does exactly this.

Affected area/feature

@Frassle
Copy link
Member

Frassle commented Jul 31, 2023

Would it be possible to run a "pulumi stack select" first and if that fails ignore and skip the destroy?
Or (maybe in conjunction with the above) we make the exit code for a stack not found error something specific, so you could do like:

pulumi destroy
EC=$?
if $EC -eq 404; then
  echo "stack missing, ignore"
else
  exit $EC
fi

@passcod
Copy link
Author

passcod commented Jul 31, 2023

I mean this issue is specifically about the action; if I was using the CLI directly I would have it solved already.

@Frassle
Copy link
Member

Frassle commented Jul 31, 2023

🤦‍♂️ I didn't even notice what repo I was in.

Yes something like this sounds reasonable.
I think the only question is if this flag should only apply to destroy actions, or also to updates?

@Frassle Frassle added the kind/enhancement Improvements or new features label Jul 31, 2023
@passcod
Copy link
Author

passcod commented Jul 31, 2023

Ah, yes I suppose it could also apply to updates, so long as upsert isn't given (both as it's nonsensical and also to avoid passing if the stack create fails for some reason).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

2 participants