Feature Request: Manual changeset approval via CLI

[mipearson]

🚀 Feature Request

General Information

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

Description

This is similar to #2879, but my use case is less CI/CD and more CLI workflow.

Our existing tool (https://github.com/envato/stack_master) has the following workflow:

1. stack_master apply <stack> (similar to cdk deploy <stack>)
2. Stack Master creates the changeset, presents what would be changed/replaced/etc to the user
3. User verifies the changeset by pressing y
4. Changeset is applied

This is similar to CDK's behaviour if IAM changes are detected.

We've come to rely on this behaviour - it gives us confidence that the changes we're about to make don't accidentally replace something they shouldn't (eg, an RDS instance) or have other unexpected behaviour that doesn't show up in a simple diff.

From what I can tell, cdk diff infers what would be changed rather than creating a changeset, so there's the possibility that its idea of what would occur and what would actually happen may be different. For example, in "traditional" cloudformation, I've had updates occur on converting a JSON template to a YAML one, with no other changes.

Proposed Solution

Add a command line option (--confirm, maybe?) that always asks the user if they'd like to apply the proposed changset.

Add this to cdk.json as well so that it can be set on a per-project basis.

Add --no-confirm to override this in the CLI.

[rhboyd]

+1 for the --confirm flag

[konstantinj]

Heavy +1 from my side since we were using this confirmed workflow as well. Currently we can't use cdk for production because of this.

[eladb]

UX-wise it probably make sense to tie this into --require-approval

[konstantinj]

In a couple of weeks from now on I would have time for that. I guess creating an else here would be sufficient: https://github.com/aws/aws-cdk/blob/master/packages/aws-cdk/lib/api/deploy-stack.ts#L91

[konstantinj]

Would it be an option to just show a link to the console to review the changes there as a first version?
Creating those nice cli tables for a changeset seems quite sophisticated.

[stevehodgkiss]

It would be great to have this feature in aws-cdk! Changes can't be safely deployed without it, since there's no way to review the changeset beforehand. Currently, external tools would need to be used in combination with --no-execute and --change-set-name ... in order to review changesets before executing them.

My suggestion would be to add the same flags / UI as aws sam cli:

Source

[stevehodgkiss]

Made a start on this in #15494 Interested in your thoughts!

[nija-at]

I have a feeling this change would benefit from an RFC.

@eladb - wdyt? Should we move this to the rfc repo and start from there?

[eladb]

@nija-at Yes, a short RFC to discuss and approve the CLI APIs is likely a good idea as it will allow us to muse about the correct switches/behaviors.

Generally I really like where #15494 is going.

@stevehodgkiss are you able to kick off an RFC process for this?

[stevehodgkiss]

@eladb I think it would be better and faster if someone from aws drove the RFC and feature / code changes. Happy to provide feedback on the RFC when it's out though.

[adrian-skybaker]

When deploying from a build agent in a CICD tool, waiting for input from stdin (eg keyboard) is awkward, but manual review of changes is still useful. Ideally we'd be able to leverage the same support to run a cdk command that created the changeset, and printed it in a friendly format, then in a separate later command, deployed the changeset. See https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation for an example - it's a task that will pause in between two separate, standalone bash commands.

In theory you could glue this together yourself now, I haven't tried, but at a glance a couple of things look painful:

• you'd have to scrape the id of the changeset that cdk deploy --execute=false creates from the CLI output, I can't see a way to get this in a structured/API way.
• you'd have to do the print of the changeset yourself, which is extra painful when you're relying on the automatic cross account role assumption of the CDK. Alternatively you can just leave the cdk deploy output, and let the approver copy-paste the id, hope into console to review etc, but that's clunky.

[madeline-k]

Related: #679 #1629 #19504