(cli): CDK Synth CLI command doesn't included stacks in nested cloud assemblies #28283
Labels
bug
This issue is a bug.
cli
Issues related to the CDK CLI
p2
package/tools
Related to AWS CDK Tools or CLI
Describe the bug
When calling
cdk synth
on an app that has nested cloud assemblies (in this case,Stage
subclass representing an application instance), the list of stacks printed after synthesis omits any stacks from the nested assembly.This issue was described before, but closed when only part of the complaint was addressed: #18599
Expected Behavior
I would expect all synthesized stacks to be listed
Current Behavior
Only stacks that are direct children of the top level
App
are printed.Reproduction Steps
I've constructed a reproduction here: https://github.com/haljarrett/cdk-stage-issue/tree/master
In it, I have an App with two top level Stacks and a Stage, which itself has a Stack. Only the two top level stacks are printed when
cdk synth
is executed:Compare this to the correct output of
cdk list
:Possible Solution
My thought is that this is arising from the way stacks are being selected from the root cloud assembly;
In cdk-toolkit.ts->synth we have the print statement generating this output, which uses stacks found from selectStackForDiff.
This method pulls the stacks from the root cloud assembly with
assembly.selectStacks
, specifying the behavior asMainAssembly
on line 750. My suggestion would be to move this behavior toDefaultSelection.AllStacks
, which would pull stacks recursively from nested assemblies.Additional Information/Context
I am looking to move towards (and guide my team towards) using a CDK pattern that leverages
Stage
subclasses as the top level abstractionl; not being able to see / deploy the stacks that are built under a stage is a papercut when doing this.CDK CLI Version
2.114.1 (build 02bbb1d)
Framework Version
No response
Node.js Version
v20.6.0
OS
MacOS
Language
TypeScript
Language Version
~5.2.2
Other information
Noted in the above, but unless there is a strong reason to only use stacks from the main assembly in this output, this should be a trivial fix - maybe if I find some time over the weekend I'll review the contribution guidelines and cut a PR.
The text was updated successfully, but these errors were encountered: