Introduce destroy command

[VOVELEE]

Details

Currently branch-deploy supports noop and deploy commands and this works great.
In order to manage complete lifecycle of deployments - will it be possible to introduce destroy command?

[GrantBirki]

@VOVELEE I could certainly see this being added as a feature. Here are some questions to expand upon this:

• How would you expect this to work or to be used in detail?
• Would you want the command to be named .delete or .destroy by default?
• Should the "destroy" command trigger a new deployment event to a given environment (the little green rocket) or should it not create one since it is removing resources? I would imagine it should be treated as a deployment event (even though it is removing things) so the branch protection rules that are configured for a project (requiring deployments) would still allow merges - After all, it is still a deployment, just one that involves the removal of something.

Under the hood, I would imagine this new feature to work almost identically to the .deploy command. It would just set slightly different outputs so users could conditionally run different steps in their workflows. It would also create a deployment event.

Also very interested in this, so I'll chime in!

How would you expect this to work or to be used in detail?

I already built this out as a separate workflow myself. All of the destroying is done via an in-house GitHub Action, so really it would be some window dressing so we that could consolidate the logic better. If it output an "action" for "deploy" vs "destroy" then we could key off that and proceed from there.

It would be great if it could allow people to destroy deployments from others (i.e. someone goes on vacation, I want to remove the resources now until they're back, or proactively destroy it if there was a QA issue and it goes back for more development).

One benefit would be building in the inability to trigger a new deployment while the destroy is still in progress, as well. Even better would be an option to chain them, so I could specify "destroy, then deploy" which in some cases is far more desirable if something like k8s resources get into weird states.

Would you want the command to be named .delete or .destroy by default?

Anecdotally, I use destroy terminology right now.

Should the "destroy" command trigger a new deployment event to a given environment

Given the above ideas, I think setting it as a deployment would make sense since you probably don't want to allow overlapping of a deploy/destroy for the same resources.

[GrantBirki]

@houserx-jmcc thanks for the reply! I think there is enough consensus then on what this feature should consist of. I'll try and prioritize this and get it added soon!

[GrantBirki]

@houserx-jmcc and @VOVELEE, I started doing some implementation on this and after coding a decent chunk of it, I am ultimately going to abandon this work. I have opened a PR draft of how far I got as a reference: #406.

My main reasoning for not continuing this work, is I don't like how many parts of the codebase this change would touch and the possibilities of things breaking.

I took the approach of basically just making .destroy an alias of .deploy but setting a special destroy: true output from this Action. Doing all this work just to have one extra output that a subsequent workflow step would read just feels far too risky of a change for what it is worth.

Today, the exact same "destroy" logic could be captured by using input parameters which this Action natively supports today. It might not be the cleanest approach, but it will do the job: .deploy | --destroy for example. You can read more about parameters here.

It would be very nice and clean to have a .destroy command, but right now I'm really prioritizing the stability, security, and safety of this project over QoL features.

This might not be the best news but I think that custom "destroy" logic can be implemented via parameters and then custom handling of those params in subsequent workflow steps.

Now if you need to do some really custom logic, you could always attempt to adapt the sister project of github/branch-deploy to suit your needs to run any custom workflow: https://github.com/github/command

@GrantBirki As I read that, it totally made sense, and definitely made me realize there's a lot more we can do with what we already have - thank you for writing down your thoughts!

I will probably give this a go based on what you described, as I do think it will get us quite close, if not all the way, to what we want.

Maybe the destroy functionality could make sense in the documentation as a "recipe" for others to follow? I'm happy to post back our approach/learnings here if this works for us.

[GrantBirki]

Maybe the destroy functionality could make sense in the documentation as a "recipe" for others to follow? I'm happy to post back our approach/learnings here if this works for us.

That would be great! I have found that people actually search back through these issues quite a bit so anything you share will certainly help someone else in the future.

Also, if you come up with a great "recipe" or strategy that others can use, we can update the official docs in this repo as well to reflect that. Thanks! ❤️