-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(codedeploy): ignoreAlarmConfiguration parameter to Deployment Groups #26957
Conversation
…ment groups The alarms on a CodeDeploy group are configurable to be enabled or disabled through the SDK or UI. Bringing in that functionality to the CDK to have parity.
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.
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.
Thanks (and sorry for the late review)! 👍
Looks good overall.
In my opinion, there are some missing unit tests and a slight adjustment in parameter ordering.
@@ -884,4 +884,33 @@ describe('CodeDeploy ECS DeploymentGroup', () => { | |||
)); | |||
}); | |||
}); | |||
|
|||
test('can ignore alarm status when alarms are present', () => { |
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.
Test cases should be added for each deployment group to verify that the configuration is disabled when ignoreAlarmConfiguration: true
, alarms
is not empty, and the @aws-cdk/aws-codedeploy:removeAlarmsFromDeploymentGroup
feature flag is enabled (this condition).
removeAlarms = true, | ||
ignoreAlarmConfiguration: boolean = false, |
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.
removeAlarms = true, | |
ignoreAlarmConfiguration: boolean = false, | |
ignoreAlarmConfiguration = false, | |
removeAlarms = true, |
I think it's better/clearer to keep the feature flag parameter last.
@@ -43,6 +43,7 @@ new codedeploy.LambdaDeploymentGroup(stack, 'BlueGreenDeployment', { | |||
], | |||
preHook, | |||
postHook, | |||
ignoreAlarmConfiguration: false, |
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.
ignoreAlarmConfiguration: false, |
Redundant
@@ -40,6 +40,7 @@ new codedeploy.ServerDeploymentGroup(stack, 'CodeDeployGroup', { | |||
failedDeployment: false, | |||
deploymentInAlarm: false, | |||
}, | |||
ignoreAlarmConfiguration: false, |
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.
ignoreAlarmConfiguration: false, |
Redundant
- Update parameter ordering - Add missing unit tests for removeAlarms feature flag - Drop redundant integration test changes
Thanks for the review! Sorry it took me a while to address your comments, my github notifications must be disabled. I think I addressed everything, but let me know if there's anything I missed. Appreciate the call out on the unit test I missed. |
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.
Thanks for the changes!
Just some minor adjustments to be made.
packages/aws-cdk-lib/aws-codedeploy/lib/server/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/lambda/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/ecs/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/server/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/lambda/deployment-group.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Luca Pizzini <lpizzini7@gmail.com>
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.
Hey @nrgeil thank you for opening this PR with us. I have some comments, please let me know if I can clarify anything.
CfnDeploymentGroup.AlarmConfigurationProperty | undefined { | ||
export function renderAlarmConfiguration( | ||
alarms: cloudwatch.IAlarm[], | ||
ignorePollAlarmFailure?: boolean, |
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.
Hey, why is this optional now?
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.
It was possible to be undefined before. Correct me if I'm wrong, but isn't this equivalent? It got called out in community review to simplify, but I'd be happy to revert.
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.
It is equivalent. Ideally this would have been part of a property bag to begin with, but now doing so is a breaking change. So no update needed here.
ignoreAlarmConfiguration = false, | ||
removeAlarms = true, |
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.
I believe the new property should be at the end. Since this is an exported function, someone could be using it and now their third parameter would be referencing another argument.
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.
Funny enough, that's what I had originally. There was a request to flip it here for readability, but to your point usability should probably supersede.
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.
@vinayak-kukreja is right, we cannot flip it because it would be a breaking change to flip. However, I have an alternate solution: we deprecate renderAlarmConfiguration
entirely and build renderAlarmConfigurationV2
.
It would look like this:
export function renderAlarmConfiguration(alarms: cloudwatch.IAlarm[], ignorePollAlarmFailure: boolean | undefined, removeAlarms = true) {
return renderAlarmConfigurationV2({ alarms, ignorePollAlarmFailure, removeAlarms });
}
export interface renderAlarmConfigProps {
readonly alarms: cloudwatch.IAlarm[],
readonly ignorePollAlarmFailure?: boolean,
/** default true */
readonly removeAlarms?: boolean,
// your new prop
}
export function renderAlarmConfigurationV2(props: renderAlarmConfigProps) {
// the original implementation plus your new prop
}
This would mean updating all the places we use renderAlarmConfiguration
to renderAlarmConfigurationV2
, but I think this is the correct path to go down.
Nudging you again @nrgeil. Let us know if you are willing to continue work on this PR! |
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.
Sorry about the delayed response, missed the github notifications.
Thanks for the review! The comments conflict a little with the previous community review, so let me know how you'd like me to proceed. I'll hold off on pushing a new commit until I have clarification.
CfnDeploymentGroup.AlarmConfigurationProperty | undefined { | ||
export function renderAlarmConfiguration( | ||
alarms: cloudwatch.IAlarm[], | ||
ignorePollAlarmFailure?: boolean, |
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.
It was possible to be undefined before. Correct me if I'm wrong, but isn't this equivalent? It got called out in community review to simplify, but I'd be happy to revert.
ignoreAlarmConfiguration = false, | ||
removeAlarms = true, |
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.
Funny enough, that's what I had originally. There was a request to flip it here for readability, but to your point usability should probably supersede.
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.
Hi @nrgeil, thanks for responding. I looked through the outstanding comments a bit more and have just the one thing for you. The rest of the code looks good, I'm happy to approve once the comment is addressed. Thanks for your contributions!
ignoreAlarmConfiguration = false, | ||
removeAlarms = true, |
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.
@vinayak-kukreja is right, we cannot flip it because it would be a breaking change to flip. However, I have an alternate solution: we deprecate renderAlarmConfiguration
entirely and build renderAlarmConfigurationV2
.
It would look like this:
export function renderAlarmConfiguration(alarms: cloudwatch.IAlarm[], ignorePollAlarmFailure: boolean | undefined, removeAlarms = true) {
return renderAlarmConfigurationV2({ alarms, ignorePollAlarmFailure, removeAlarms });
}
export interface renderAlarmConfigProps {
readonly alarms: cloudwatch.IAlarm[],
readonly ignorePollAlarmFailure?: boolean,
/** default true */
readonly removeAlarms?: boolean,
// your new prop
}
export function renderAlarmConfigurationV2(props: renderAlarmConfigProps) {
// the original implementation plus your new prop
}
This would mean updating all the places we use renderAlarmConfiguration
to renderAlarmConfigurationV2
, but I think this is the correct path to go down.
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
@nrgeil pinging you again on this; this PR will soon be closed without any action |
Pull request has been modified.
…urationV2 - Create props class - Documentation updates - Update implementation to handle defaults
*/ | ||
readonly ignorePollAlarmFailure?: boolean, | ||
/** | ||
* When no alarms are provided on an update, removes previously existing alarms from the construct. |
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.
Please correct me if I'm wrong, but I believe this is what's happening. It was pretty unclear to me what exactly this did so I wanted to make sure it got documented.
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.
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.
Thanks @nrgeil I will work to get this one in. Thanks for your patience :)
packages/aws-cdk-lib/aws-codedeploy/lib/ecs/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/ecs/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/lambda/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/lambda/deployment-group.ts
Outdated
Show resolved
Hide resolved
packages/aws-cdk-lib/aws-codedeploy/lib/server/deployment-group.ts
Outdated
Show resolved
Hide resolved
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.
Hopefully my changes pass the build :)
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). |
…oups (#26957) The alarms on a CodeDeploy group are configurable to be enabled or disabled through the SDK or UI. Bringing in that functionality to the CDK to have parity. The parameter name mirrors the "Ignore alarm configuration" checkbox in the alarm configuration section of the UI. Motivation: Developers are able to disable _rollback_ on alarm, but this leaves deployments in a stopped state should any alarms be active. Including this configuration will align with the expectation that alarms will not block a deployment in lower environments via a flag rather than logic to include/exclude alarms on the deployment group based on environment. I'm sure there are other use cases for disabling the alarm configuration on a deployment group. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The alarms on a CodeDeploy group are configurable to be enabled or disabled through the SDK or UI. Bringing in that functionality to the CDK to have parity. The parameter name mirrors the "Ignore alarm configuration" checkbox in the alarm configuration section of the UI.
Motivation: Developers are able to disable rollback on alarm, but this leaves deployments in a stopped state should any alarms be active. Including this configuration will align with the expectation that alarms will not block a deployment in lower environments via a flag rather than logic to include/exclude alarms on the deployment group based on environment. I'm sure there are other use cases for disabling the alarm configuration on a deployment group.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license