-
Notifications
You must be signed in to change notification settings - Fork 4k
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
cdk destroy failed to destroy s3 bucket after codepipeline push artifact #1269
Labels
Comments
You are right, we should be making this easier. |
rix0rrr
added
feature-request
A feature should be added or improved.
@aws-cdk/aws-s3
Related to Amazon S3
labels
Dec 2, 2018
rix0rrr
changed the title
cdk destroy failed to destroy s3 bucket after codepipeline push artifact
bucket: add 'retain' property
Dec 2, 2018
We should make it possible to configure the retention policy at the L2 level, and probably default it to |
Aha, my mistake. We already have this property. If you create your bucket like this: new s3.Bucket(this, 'Bucket', {
/// ...
removalPolicy: cdk.RemovalPolicy.Orphan
}); Stack deletion will not complain. |
rix0rrr
changed the title
bucket: add 'retain' property
cdk destroy failed to destroy s3 bucket after codepipeline push artifact
Dec 3, 2018
rix0rrr
added a commit
that referenced
this issue
Dec 3, 2018
Switch the default RemovalPolicy of a Bucket to Orphan. This reduces friction for users with stacks that contain Buckets. In the 99% of cases right now, any activity on a Bucket will cause the stack to fail to delete, and customers are left wondering how to fix this situation (see #1269 for example). It seems better to default to the frictionless case, and have people opt-in to hard deletes if they know for a fact the operation is going to work.
9 tasks
rix0rrr
added a commit
that referenced
this issue
Dec 6, 2018
Switch the default RemovalPolicy of a Bucket to Orphan. This reduces friction for users with stacks that contain Buckets. In the 99% of cases right now, any activity on a Bucket will cause the stack to fail to delete, and customers are left wondering how to fix this situation (see #1269 for example). It seems better to default to the frictionless case, and have people opt-in to hard deletes if they know for a fact the operation is going to work.
We've made the orphaning behavior default. For new stacks, you will not experience this behavior anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
My demo app builds codebuild and codepipeline, after two commits to codecommit and successfully build, I decided to destroy everything:
But s3 bucket was not deleted:
Expect:
Either state that cdk destroy doesn't destroy s3 buckets, or successfully delete s3 bucket.
The text was updated successfully, but these errors were encountered: