Open mipearson opened 5 years ago
+1 for the --confirm flag
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.
UX-wise it probably make sense to tie this into --require-approval
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
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.
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:
Made a start on this in https://github.com/aws/aws-cdk/pull/15494 Interested in your thoughts!
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?
@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 https://github.com/aws/aws-cdk/pull/15494 is going.
@stevehodgkiss are you able to kick off an RFC process for this?
@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.
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:
cdk deploy --execute=false
creates from the CLI output, I can't see a way to get this in a structured/API way.
:rocket: Feature Request
General Information
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:
stack_master apply <stack>
(similar tocdk deploy <stack>
)y
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.