chore(aws-cdk): Revert "fix(aws-cdk): include nested stacks when building changesets …

[madeline-k]

…(#19494)"

This reverts commit 97cc8e2.

Reverting this commit since it introduced a regression. Or, it is not a regression but the regression runs of the CLI integ tests think it is. The same test fails in the run-against-latest-release and the run-against-latest-code regression test suites: https://github.com/aws/aws-cdk/blob/master/packages/aws-cdk/test/integ/cli/cli.integtest.ts#L629.

Test fails with:

    expect(received).not.toEqual(expected) // deep equality

    Expected: not "arn:aws:cloudformation:ap-southeast-2:416588550161:changeSet/cdk-deploy-change-set/c8c68622-fc38-4199-81b2-b74206380152"
      at cli.integtest.ts:644:38
          at runMicrotasks (<anonymous>)
      at ../helpers/cdk.ts:130:7
      at ResourcePool.using (../helpers/resource-pool.ts:44:14)
      at ../helpers/test-helpers.ts:38:14

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use cdk-integ to deploy the infrastructure and generate the snapshot (i.e. cdk-integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[mergify]

Title does not follow the guidelines of Conventional Commits. Please adjust title before merge.

[mergify]

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: 090b158
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[flyingImer]

@madeline-k curious - what's the next step for this to roll out again? do you have a issue link to track?

[madeline-k]

Hey @flyingImer, I just re-opened the original issue that this PR closed #19224. We will track it there.

[gagipro]

any news on that ?

[skinny85]

I thought #18207 fixed this, so that cdk diff now works for nested stacks?

[gagipro]

I thought #18207 fixed this, so that cdk diff now works for nested stacks?

I don't think so. You cannot have nested stack details in your changeset with --no-execute.

#19224 (comment)

I managed to make it work with the help of this link, but should be included since long time !!!

[skinny85]

But why do you need to review changes in the changeset, if you have a working cdk diff command?

[gagipro]

But why do you need to review changes in the changeset, if you have a working cdk diff command?

because everything is in an automated pipeline. A request for a change is made and someone as to review later and validate or reject the change.

and that's the way CloudFormation do work.

anyway : by patching the code : it do work as intended, see url I posted.

This needs to be adressed to behave the same as CloudFormation

[skinny85]

Can't they review the output of cdk diff? Isn't that much nicer than looking at ChangeSet diffs, which contain a lot of noise from what I remember?

[gagipro]

Can't they review the output of cdk diff? Isn't that much nicer than looking at ChangeSet diffs, which contain a lot of noise from what I remember?

Try it.

Cdk diff : you need cli and direct Access.
Validate a changeset is in the console, red or green graphical interface that permits to inspect dozens of sub nested stacks.

I will now open a ticket through enterprise support to see if they Can prioritize this issue.

I tried a patched deploy-stack.js aws-cdk lib and it seems to be ok.

So I'm wondering why they don't implement.

Probable you know if it breaks something else if you are aws cdk dev.

[konstantinj]

@gagipro I've tried through enterprise already but please try as well.
@skinny85 IMO cdk diff is different since it will not fail fast. Example: For some change a new resource needs to be created but there is already a resource with that name. Creating a changeset with CFN will fail then before any change to the stack as a whole will hpapen. With cdk diff I won't see that and my stack update will fail during the actual update and needs to roll back. In production. That's not ideal.

[gagipro]

@gagipro I've tried through enterprise already but please try as well. @skinny85 IMO cdk diff is different since it will not fail fast. Example: For some change a new resource needs to be created but there is already a resource with that name. Creating a changeset with CFN will fail then before any change to the stack as a whole will hpapen. With cdk diff I won't see that and my stack update will fail during the actual update and needs to roll back. In production. That's not ideal.

Hi @konstantinj

Enterprise support already replied to check with devs on github.

    "sed -i 's/            ResourcesToImport: this.options.resourcesToImport,/            IncludeNestedStacks: true,\\n            ResourcesToImport: this.options.resourcesToImport,/g' /usr/local/lib/node_modules/aws-cdk/lib/api/deploy-stack.js",
    "sed -i 's/ResourcesToImport:this.options.resourcesToImport,/IncludeNestedStacks:true,ResourcesToImport:this.options.resourcesToImport,/g' /usr/local/lib/node_modules/aws-cdk/lib/index.js"

[skinny85]

@skinny85 IMO cdk diff is different since it will not fail fast. Example: For some change a new resource needs to be created but there is already a resource with that name. Creating a changeset with CFN will fail then before any change to the stack as a whole will hpapen. With cdk diff I won't see that and my stack update will fail during the actual update and needs to roll back. In production. That's not ideal.

Thanks for the explanation @konstantinj - I actually did not know ChangeSets worked this way.