-
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
feat(cli): cdk rollback #31684
feat(cli): cdk rollback #31684
Conversation
Add a CLI feature to roll a stuck change back. This is mostly useful for deployments performed using `--no-rollback`: if a failure occurs, the stack gets stuck in an `UPDATE_FAILED` state from which there are 2 options: - Try again using a new template - Roll back to the last stable state There used to be no way to perform the second operation using the CDK CLI, but there now is. `cdk rollback` works in 2 situations: - A paused fail state; it will initiating a fresh rollback (on `CREATE_FAILED`, `UPDATE_FAILED`). - A paused rollback state; it will retry the rollback, optionally skipping some resources (on `UPDATE_ROLLBACK_FAILED` -- it seems there is no way to continue a rollback in `ROLLBACK_FAILED` state). `cdk rollback --orphan <logicalid>` can be used to skip resource rollbacks that are causing problems. `cdk rollback --force` will look up all failed resources and continue skipping them until the rollback has finished. This change requires new bootstrap permissions, so the bootstrap stack is updated to add the following IAM permissions to the `deploy-action` role: ``` - cloudformation:RollbackStack - cloudformation:ContinueUpdateRollback ``` These are necessary to call the 2 CloudFormation APIs that start and continue a rollback. Relates to (but does not close yet) #30546. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Can you point out the fix in this PR compared to the original failed attempt? Edit: This is it https://github.com/aws/aws-cdk/pull/31684/files/efdf9b59bdda923b4814fdb102f72ead17479992..7bc575f45b5f301f76af55e312bb9161aaf123cd |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Comments on closed issues and PRs are hard for our team to see. |
This is a re-draft of #31407. All description and motivation of the previous PR still apply.
The previous PR caused a regression because some
CREATE_IN_PROGRESS
events for CloudFormation do not have aPhysicalResourceId
.Fix that issue in this PR. Update the existing unit test that was supposed to catch this issue previously, it did not set a
ResourceStatus
which caused the event to be skipped for the wrong reason.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license