fix(cli): deploy and destroy with `--all` option fail on apps with no top-level stacks by go-to-k · Pull Request #985 · aws/aws-cdk-cli

go-to-k · 2025-12-10T18:12:36Z

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

…top-level stacks fix

codecov-commenter · 2025-12-10T18:24:03Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.98%. Comparing base (4813f35) to head (989cb78).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #985      +/-   ##
==========================================
+ Coverage   87.72%   87.98%   +0.26%     
==========================================
  Files          72       72              
  Lines       10077    10082       +5     
  Branches     1327     1335       +8     
==========================================
+ Hits         8840     8871      +31     
+ Misses       1212     1186      -26     
  Partials       25       25

Flag	Coverage Δ
suite.unit	`87.98% <100.00%> (+0.26%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…l-on-stage-only

docs docs

rix0rrr

I don't think this behavior is desirable or intuitive.

The constraints are:

--all was introduced before Stages existed. When Stages were introduced, it would continue to select stacks only in the top-level assembly.
Stages are intended to be deployed using a pipeline in the same application. For that use case, you don't really want to select them using cdk deploy.
I think having a "sometimes cdk deploy deploys stacks in stages and sometimes not" kind of behavior will be extremely confusing.

I understand this might be desirable for your specific use case, but is your use case represenative?

As written on your issue,

$ cdk deploy '**'

Should solve your particular problem exactly, and it's not that much more to type than --all.

Don't get me wrong: I'm not against making changes here altogether. But I think it should be a co-operation between the CDK app and the CLI. Perhaps a Stack gets a new option that interplays with a new selection mechanism:

new Stack(this, 'SomeStack', {
  deployUsingCli: WITH_ALL_FLAG | ONLY_IF_EXPLICITLY_SELECTED | NEVER,
});

And then we set appropriate defaults to retain existing behavior.

I'm also not opposed to changing the documentation to better reflect actual behavior.

But as-is, I think changing this behavior in the CLI only will get too confusing.

Fixes aws/aws-cdk#32836, aws/aws-cdk#32545, aws/aws-cdk#27179, aws/aws-cdk#22240 ## Reason for this change This PR implements the feature that warns users when non-existent stacks are specified in `cdk destroy`. * It does not display the message `Are you sure you want to delete:` if there is no matching stack. * Even if the stack does not exist, `cdk destroy` will not fail, it will just print a warning. For examples (that have `Stacka`, `StackA`, `StackX`): <img width="355" height="56" alt="destroy2" src="https://github.com/user-attachments/assets/0ac39df5-7ec7-46a4-8572-f61bb7f26ec6" /> <br> <img width="414" height="85" alt="destroy3" src="https://github.com/user-attachments/assets/9c897485-71a9-4c93-9d00-4ed5a5f8df15" /> <br> <img width="315" height="56" alt="destroy4" src="https://github.com/user-attachments/assets/d208e590-f3c8-4228-87df-0797202a6224" /> ## Difference from previous PR The [previous PR](aws/aws-cdk#32636) was reverted in aws/aws-cdk#32839 due to a regression with only nested stage stacks. So this version addresses that regression with comprehensive tests. ## Description of changes The original implementation added warnings for non-existent stacks in `cdk destroy`, but it failed when applications had only nested stage stacks (no top-level stacks). This happened because the code used `allTopLevel: true`, which only searched for stacks directly under the App, ignoring stacks within nested Stages. Fixed the regression by changing `suggestStacks` method to use `DefaultSelection.AllStacks` instead of `allTopLevel: true`, ensuring the warning feature works for all stack configurations (top-level only, nested only, or both). Added regression tests to verify the fix for the nested stage scenario. ```diff private async suggestStacks(props: { selector: StackSelector; stacks: StackCollection; exclusively?: boolean; }) { const assembly = await this.assembly(); const selectorWithoutPatterns: StackSelector = { - ...props.selector, - allTopLevel: true, patterns: [], }; const stacksWithoutPatterns = await assembly.selectStacks(selectorWithoutPatterns, { extend: props.exclusively ? ExtendedStackSelection.None : ExtendedStackSelection.Downstream, - defaultBehavior: DefaultSelection.OnlySingle, + defaultBehavior: DefaultSelection.AllStacks, }); ``` ## Additional Information When running `cdk destroy --all` or `cdk deploy --all` against a configuration with **no top-level stacks (nested stages only)**, the following error occurs. However, this behavior existed **before this PR** and is unrelated to the changes made here. Since it is outside the scope of this PR, no fix has been implemented for this behavior. FYI: I have submitted an [issue](aws#1003) and a [PR](aws#985) about this behavior. ```ts const app = new cdk.App(); new MyStage(app, 'MyStage'); // This has CdkSampleStack ``` ``` > cdk deploy Since this app includes more than a single stack, specify which stacks to use (wildcards are supported) or specify `--all` Stacks: MyStage/CdkSampleStack > cdk deploy --all ... No stack found in the main cloud assembly. Use "list" to print manifest > cdk destroy --all ... No stack found in the main cloud assembly. Use "list" to print manifest ``` --- By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license --------- Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Otavio Macedo <288203+otaviomacedo@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Momo Kornher <kornherm@amazon.co.uk>

fix(cli): deploy and destroy with --all option fails on apps with no …

7643c1f

…top-level stacks fix

go-to-k had a problem deploying to integ-approval December 10, 2025 18:12 — with GitHub Actions Failure

aws-cdk-automation enabled auto-merge December 10, 2025 18:12

aws-cdk-automation requested a review from a team December 10, 2025 18:13

github-actions Bot added the p2 label Dec 10, 2025

go-to-k mentioned this pull request Dec 10, 2025

feat(cli): warn of non-existent stacks in cdk destroy #984

Merged

integ

9550003

auto-merge was automatically disabled December 10, 2025 18:25
Head branch was pushed to by a user without write access

go-to-k had a problem deploying to integ-approval December 10, 2025 18:25 — with GitHub Actions Failure

go-to-k marked this pull request as draft December 10, 2025 18:47

go-to-k marked this pull request as ready for review December 10, 2025 19:06

go-to-k marked this pull request as draft December 10, 2025 19:06

go-to-k had a problem deploying to integ-approval December 13, 2025 15:32 — with GitHub Actions Failure

go-to-k force-pushed the all-on-stage-only branch from 807c8bc to 9550003 Compare December 13, 2025 15:38

go-to-k had a problem deploying to integ-approval December 13, 2025 15:39 — with GitHub Actions Failure

use StackCollection

b0ae317

go-to-k had a problem deploying to integ-approval December 20, 2025 16:39 — with GitHub Actions Failure

revert the process to original code

73e8ac1

go-to-k had a problem deploying to integ-approval December 20, 2025 16:42 — with GitHub Actions Failure

add a nre condition using DefaultSelection.AllStacks

04716ee

go-to-k had a problem deploying to integ-approval December 20, 2025 16:47 — with GitHub Actions Failure

wip

cab7827

go-to-k had a problem deploying to integ-approval December 20, 2025 16:49 — with GitHub Actions Failure

wip

e29c54e

go-to-k had a problem deploying to integ-approval December 20, 2025 17:34 — with GitHub Actions Failure

pahud mentioned this pull request Jan 2, 2026

(cli): deploy and destroy with --all option fails on apps with no top-level stacks #1003

Closed

1 task

Merge branch 'main' of https://github.com/go-to-k/aws-cdk-cli into al…

ad1dcde

…l-on-stage-only

go-to-k had a problem deploying to integ-approval January 10, 2026 15:49 — with GitHub Actions Failure

modify

a4c3f26

go-to-k had a problem deploying to integ-approval January 10, 2026 16:24 — with GitHub Actions Failure

go-to-k marked this pull request as ready for review January 10, 2026 16:27

go-to-k had a problem deploying to integ-approval January 10, 2026 16:42 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval January 10, 2026 16:47 — with GitHub Actions Failure

docs

989cb78

docs docs

go-to-k force-pushed the all-on-stage-only branch from dd751ed to 989cb78 Compare January 10, 2026 16:47

go-to-k had a problem deploying to integ-approval January 10, 2026 16:48 — with GitHub Actions Failure

go-to-k changed the title ~~fix(cli): deploy and destroy with --all option fails on apps with no top-level stacks~~ fix(cli): deploy and destroy with --all option fail on apps with no top-level stacks Jan 13, 2026

rix0rrr requested changes Jan 22, 2026

View reviewed changes

mrgrain closed this Jan 28, 2026

go-to-k deleted the all-on-stage-only branch January 28, 2026 12:23

Navigation Menu

Uh oh!

fix(cli): deploy and destroy with `--all` option fail on apps with no top-level stacks - #985

fix(cli): deploy and destroy with `--all` option fail on apps with no top-level stacks#985
go-to-k wants to merge 10 commits into
aws:mainfrom
go-to-k:all-on-stage-only

go-to-k commented Dec 10, 2025 •

edited

Loading

Uh oh!

codecov-commenter commented Dec 10, 2025 •

edited

Loading

Uh oh!

rix0rrr left a comment •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

go-to-k commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov-commenter commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

rix0rrr left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

go-to-k commented Dec 10, 2025 •

edited

Loading

codecov-commenter commented Dec 10, 2025 •

edited

Loading

rix0rrr left a comment •

edited

Loading