-
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
[cli] Caller should be able to override created changeset name #11075
[cli] Caller should be able to override created changeset name #11075
Comments
We could add this. Out of curiosity: have you considered using CDK Pipelines? |
I would like to see this feature. I want to continue using gitlabci and don't want to switch :-) |
The CDK automatically deletes empty change sets, so I'm wondering if an additional flag is needed to retain empty change sets. Otherwise, use cases for externally executing the change set would need to check for its existence before executing to avoid errors. For @muja's case with the CodePipeline Cloudformation action, the action fails if the change set with the provided name doesn't exist. I'm not very familiar with Codepipeline, but didn't see a straight-forward way to conditionally skip that Cloudformation action. The action is successful when the change set is empty, so retaining it would solve the problem. |
…lways produce one (even if empty) (#12683) closes #11075 Adds two commands to the `deploy` CLI command to make it easier to externally execute change sets when using the `--no-execute` flag: `--change-set-name`: Optional name of the CloudFormation change set to create, instead of using a random one. An external script or the CodePipeline CloudFormation action can use this name to later deploy the changes. `--retain-empty-change-set`: Optionally retain empty change sets instead of deleting them. This is useful for the (requested) CodePipeline use case, since the CodePipeline CloudFormation action always requires a change set, even if it's empty. Questions for reviewer: - Is `--retain-empty-change-set` needed? One workaround for the CodePipeline use case could be for users to write a lambda that generates the required empty change set whenever CDK doesn't generate one. Another idea would be to automatically retain change sets when using `--no-execute` to avoid this extra CLI flag, but this would be a small change in behavior. - Are the new integration tests overkill? Also should unit tests be added or in-place of the integration tests?
|
…lways produce one (even if empty) (aws#12683) closes aws#11075 Adds two commands to the `deploy` CLI command to make it easier to externally execute change sets when using the `--no-execute` flag: `--change-set-name`: Optional name of the CloudFormation change set to create, instead of using a random one. An external script or the CodePipeline CloudFormation action can use this name to later deploy the changes. `--retain-empty-change-set`: Optionally retain empty change sets instead of deleting them. This is useful for the (requested) CodePipeline use case, since the CodePipeline CloudFormation action always requires a change set, even if it's empty. Questions for reviewer: - Is `--retain-empty-change-set` needed? One workaround for the CodePipeline use case could be for users to write a lambda that generates the required empty change set whenever CDK doesn't generate one. Another idea would be to automatically retain change sets when using `--no-execute` to avoid this extra CLI flag, but this would be a small change in behavior. - Are the new integration tests overkill? Also should unit tests be added or in-place of the integration tests?
I believe this issue was closed because the use case is taken care of by #12683. However the proposed solution solves at least one other use case (described in #12683 (comment)). I would like to suggest reopening this issue until the proposed solution is implemented. See PR #13024 |
…lways produce one (even if empty) (aws#12683) closes aws#11075 Adds two commands to the `deploy` CLI command to make it easier to externally execute change sets when using the `--no-execute` flag: `--change-set-name`: Optional name of the CloudFormation change set to create, instead of using a random one. An external script or the CodePipeline CloudFormation action can use this name to later deploy the changes. `--retain-empty-change-set`: Optionally retain empty change sets instead of deleting them. This is useful for the (requested) CodePipeline use case, since the CodePipeline CloudFormation action always requires a change set, even if it's empty. Questions for reviewer: - Is `--retain-empty-change-set` needed? One workaround for the CodePipeline use case could be for users to write a lambda that generates the required empty change set whenever CDK doesn't generate one. Another idea would be to automatically retain change sets when using `--no-execute` to avoid this extra CLI flag, but this would be a small change in behavior. - Are the new integration tests overkill? Also should unit tests be added or in-place of the integration tests?
closes #11075 This PR is based on @swar8080's work in #12683. Adds the following CLI flag: `--change-set-name`: Optional name of the CloudFormation change set to create, instead of using the default one. An external script or the CodePipeline CloudFormation action can use this name to later deploy the changes. Motivation: see #12683 (comment)
When invoking
cdk deploy
with the--no-execute
flag, CDK will create a changeset whose name is completely random. Usually this might be okay, but in automated environments this is unacceptable. As such, it should be possible to provide a name which CDK will use when creating a changeset (e.g. using a--change-set-name <string>
flag).Use Case
Our CI/CD environment runs on top of CodePipeline in combination with CodeBuild (and very extensive use of CDK). Naturally, our initial approach was to simply do a
cdk deploy
inside our CodeBuild containers. However, the stack creation/update itself often takes several minutes with the computing instance just waiting for the stack create to finish. This is not very cost-efficient.So, to save resources and costs, the CodeBuild containers should not execute the changeset, only create it so that CodePipeline's CloudFormationExecuteChangeSetAction can take over. However, this specific deploy action needs the changeset name which must be known at create time (the Fn::GetParam function unfortunately only works for
TemplateOverrides
, tried that already).Proposed Solution
I believe the solution is simple: the CLI should accept a
--change-set-name <string>
option, and pass this optional parameter to the deployStack function. This one should use the parameter, if provided, or fallback to the existinguuid.v4()
method. This can also be used in combination with--execute
, but there it will be significantly less interesting.Other
For our use case... we tried going with
cdk synth
andCreateStackAction
shenanigans, but this leads to many more problems:cdk synth
, so we'd have to do it all manually or introduce the cdk-assets package.NotificationArns
with this approach which are also used by usThis is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: