fix(codepipeline): allow re-deploying the pipeline stack after cdk destroy

[skinny85]

Currently, the KMS key and alias used for the default CodePipeline artifact bucket are created with RemovalPolicy.RETAIN. That is problematic when trying to re-deploy a stack after running cdk destroy, as the alias name will already be taken. Because of that, change the removal policy of both the key and the alias to RemovalPolicy.DESTROY - there is a grace period of a few days on the key before it's removed permanently, so that should be good enough if anyone needs it, and it doesn't seem like directly reading the artifacts of the pipeline is an important use case anyway, especially after it has been deleted.

Fixes #4336

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[mergify]

Thanks so much for taking the time to contribute to the AWS CDK ❤️

We will shortly assign someone to review this pull request and help get it
merged. In the meantime, please take a minute to make sure you follow this
checklist:

• PR title type(scope): text
  • type: fix, feat, refactor go into CHANGELOG, chore is hidden
  • scope: name of module without aws- or cdk- prefix or postfix (e.g. s3 instead of aws-s3-deployment)
  • text: use all lower-case, do not end with a period, do not include issue refs
• PR Description
  • Rationale: describe rationale of change and approach taken
  • Issues: indicate issues fixed via: fixes #xxx or closes #xxx
  • Breaking?: last paragraph: BREAKING CHANGE: <describe what changed + link for details>
• Testing
  • Unit test added. Prefer to add a new test rather than modify existing tests
  • CLI or init templates change? Re-run/add CLI integration tests
• Documentation
  • README: update module README to describe new features
  • API docs: public APIs must be documented. Copy from official AWS docs when possible
  • Design: for significant features, follow design process

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[eladb]

What about the bucket(s)? If we destroy the keys, there is no reason to keep the buckets, right?

Also:

1. PR title for bugs should describe the problem, not the solution
2. Please reformat the PR description (line breaks, capitazliation, backpacks, etc)

[skinny85]

What about the bucket(s)? If we destroy the keys, there is no reason to keep the buckets, right?

Unfortunately, we can't destroy the buckets, as that will fail if they're not empty, and require a manual intervention by the user. Like I said, the keys are still available for a few days, so if for some reason you want to read the artifacts, the key will be there (and you can always opt-out of the key deletion in the console if you need to keep it for longer). Anyway, based on my experience working on the @aws-cdk/aws-codepipeline module, I don't think the use-case of manually reading the CodePipeline artifacts from S3 is a very important one.

Also:

1. PR title for bugs should describe the problem, not the solution
2. Please reformat the PR description (line breaks, capitazliation, backpacks, etc)

Done.

[mergify]

Thank you for contributing! Your pull request is now being automatically merged.

[aws-cdk-automation]

AWS CodeBuild CI Report

• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository