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

Support the --exclude-protected on destroy #628

Closed
garethbudden opened this issue May 31, 2022 · 6 comments · Fixed by #925
Closed

Support the --exclude-protected on destroy #628

garethbudden opened this issue May 31, 2022 · 6 comments · Fixed by #925
Assignees
Labels
area/cicd customer/feedback Feedback from customers help-wanted We'd love your contributions on this issue kind/enhancement Improvements or new features resolution/fixed This issue was fixed
Milestone

Comments

@garethbudden
Copy link

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

For similar reasons outlined in the issue that resulted in the --exclude-protected being added to the CLI, it would be good to be able to provide this flag in the GitHub Action.

@garethbudden garethbudden added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels May 31, 2022
@mikhailshilkov mikhailshilkov added help-wanted We'd love your contributions on this issue area/cicd and removed needs-triage Needs attention from the triage team labels Jun 3, 2022
@RobbieMcKinstry
Copy link
Contributor

Hi @garethbudden , thanks for opening this issue.
I think you're definitely right, that would be a very useful feature to have! I'm wondering if the solution to allow an escape hatch with an args parameter, allowing users to specify other CLI flags beyond --exclude-protected. There are a lot of other CLI flags to which this same position applies.

What do you think @cobraz?

@CmdrSharp
Copy link

@RobbieMcKinstry I don't miss this flag specifically, but I agree that either command needs to support string input, or an args / extraArgs input needs to be supported to handle flags. There are plenty of use cases, including --save-plan or --config-file for example.

We now have to resort to installing Pulumi CLI.

@RobbieMcKinstry
Copy link
Contributor

Hm, yeah... I wonder about adding command: raw, perhaps? Then we'd specify an args: List[string] input. Maybe that still feels better than running the CLI directly.

@CmdrSharp
Copy link

That's definitely a decent option!
I'd definitely prefer the action over the CLI. Just the comment-on-pr feature of the action alone saves some work compared to running the Vault CLI.

But, having read through the action-code in an effort to make a PR; I still don't see how you feed that into pulumi-automation. From what I gather, only very specific fields are taken into account there. Perhaps it just requires a PR to that module as well :)

@RobbieMcKinstry
Copy link
Contributor

Sorry to talk across you on two threads, Commander! I'm going to link this related conversation here just for posterity, in which we discuss a possible approach to side-step automation API.

@joey-jonko-paypal
Copy link

This functionality in the GHA would be great
https://www.pulumi.com/blog/announcing-public-preview-update-plans/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cicd customer/feedback Feedback from customers help-wanted We'd love your contributions on this issue kind/enhancement Improvements or new features resolution/fixed This issue was fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants