cdklabs
How is 'cdk destroy' handled?
If I understand the approach, when you run cdk synth a Github workflow is produced and when executed the cdk.out assets are used to perform the CFN create/update stacks. What would the strategy be for cdk destroy?
Similarly what would the strategy be if you removed a stack from a stage? Looking at what is produced there would be no CFN delete added to the workflow.
Just for kicks I decided to see what it would do if I ran cdk destroy and this is what I found:
npx cdk destroy --all
writing .github/workflows/deploy.yml
No stack found in the main cloud assembly. Use "list" to print manifest
And of course when I ran list I found:
npx cdk list
writing .github/workflows/deploy.yml
example/example-one
example/example-two
But if I switch to explicitly specifying one stack it appears to comprehend the request and does a proper CFN termination.
Hi @roskelleycj! I think the answer to your question is that it's not advisable to use cdk deploy and cdk destroy alongside our pipelines products (both this one and the @aws-cdk/pipelines). The purpose of deploying your code via pipeline is to not have to call these commands.
The only reason this module requires you to run cdk synth is because we need to synthesize the deploy.yml file. It actually has nothing to do with synthesizing the cloud assembly in cdk.out, and is definitely one of the sharper edges of this module.
But cdk deploy and cdk destroy are not applicable within the context of using pipelines, since it is the pipeline that is handling your deployment. The CLI has no clue about the stacks you've deployed in your pipeline, which is why you're getting the No stack found comment.
I can tell the next question is "how do i destroy my stacks after they have been created via pipeline"? Unfortunately, I think this is a known limitation and the answer is you cannot via CDK -- you must do that in the AWS console. Here is a link to a similar question I found about CDK pipelines.
At the end of the day, the scope of cdk-pipelines-github should be exactly the same as @aws-cdk/pipelines. If you find that not to be true, then that probably warrants a feature request to this module and we'll get the two in sync again.
