Skip to content
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

Closed
1 task done
Assignees
Labels
effort/small Small work item – less than a day of effort feature-request A feature should be added or improved. good first issue Related to contributions. See CONTRIBUTING.md p2 package/tools Related to AWS CDK Tools or CLI

Comments

@muja
Copy link

muja commented Oct 23, 2020

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 existing uuid.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 and CreateStackAction shenanigans, but this leads to many more problems:

  • we have lots of assets which will not get uploaded in cdk synth, so we'd have to do it all manually or introduce the cdk-assets package.
  • CodePipeline uses some other role for the stack than CDK (which is hard to override without diving into CDK internals) and since we have KMS encrypted S3 buckets, this approach led to many hard-to-debug S3 API errors.
  • you cannot provide NotificationArns with this approach which are also used by us
  • 👋 I may be able to implement this feature request

This is a 🚀 Feature Request

@muja muja added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Oct 23, 2020
@SomayaB SomayaB changed the title [module] Caller should be able to override created changeset name [cli] Caller should be able to override created changeset name Oct 26, 2020
@github-actions github-actions bot added the package/tools Related to AWS CDK Tools or CLI label Oct 26, 2020
@rix0rrr rix0rrr added effort/small Small work item – less than a day of effort good first issue Related to contributions. See CONTRIBUTING.md p2 labels Nov 2, 2020
@rix0rrr
Copy link
Contributor

rix0rrr commented Nov 2, 2020

We could add this. Out of curiosity: have you considered using CDK Pipelines?

@SomayaB SomayaB removed the needs-triage This issue or PR still needs to be triaged. label Nov 2, 2020
@markussiebert
Copy link
Contributor

I would like to see this feature. I want to continue using gitlabci and don't want to switch :-)

@swar8080
Copy link
Contributor

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.

@mergify mergify bot closed this as completed in #12683 Feb 9, 2021
mergify bot pushed a commit that referenced this issue Feb 9, 2021
…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?
@github-actions
Copy link

github-actions bot commented Feb 9, 2021

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

TLadd pushed a commit to TLadd/aws-cdk that referenced this issue Feb 9, 2021
…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?
@Wenzil
Copy link
Contributor

Wenzil commented Feb 15, 2021

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

NovakGu pushed a commit to NovakGu/aws-cdk that referenced this issue Feb 18, 2021
…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?
mergify bot pushed a commit that referenced this issue Feb 23, 2021
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)
This was referenced Mar 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment