-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Description
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:
$ cdk synth
Successfully synthesized to /Users/haljar/src/stage-issue/cdk.out
Supply a stack id (toplevelA, toplevelB) to display its template.
Compare this to the correct output of cdk list:
$ cdk list
toplevelA
toplevelB
beta/nested
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 as MainAssembly on line 750. My suggestion would be to move this behavior to DefaultSelection.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.