Skip to content

feat(cli,toolkit-lib): drift detection via cdk drift and toolkit.drift() #442

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 69 commits into from
May 27, 2025

Conversation

Leo10Gama
Copy link
Member

@Leo10Gama Leo10Gama commented May 1, 2025

Added an additional action and command toolkit.drift() and cdk drift, which invokes drift detection. Prints an output of the drift results listing out any resources in the stack that may have drifted.

Tested via yarn build && yarn test and adding in a few integ tests.

Running the command locally shows the following. With one resource drifted:
image

With no resources drifted: (image outdated)
image


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

@aws-cdk-automation aws-cdk-automation requested a review from a team May 1, 2025 18:24
@github-actions github-actions bot added the p2 label May 1, 2025
@rix0rrr
Copy link
Contributor

rix0rrr commented May 2, 2025

Thanks! This is a great feature to have!

I understand that we're detecting some kind of "diff" from a user point of view, but I'm very put-off by drift detection being part of cdk diff. That's just not what CDK diff historically did, and it's confusing to me. I wonder if it will be confusing to more people?

┌────────────┐            ╔═════════════╗            ┌────────────┐
│            │    diff    ║             ║    drift   │            │
│  Template  │◀──────────▶║    Stack    ║◀──────────▶│  Reality   │
│            │            ║             ║            │            │
└────────────┘            ╚═════════════╝            └────────────┘
                                                                   
                   ^                                               
               cdk diff                                            
            does this today                                        

Can we make this its own subcommand to begin with? cdk drift ?

Tested via yarn build && yarn test, which both compile.

Surely there's more? 🥹 An integ test would be nice.

Copy link
Contributor

@mrgrain mrgrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also needs integ tests and added to toolkit-lib (see Rico's comments).

If we are adding this as a new action/command, the action code should live in toolkit-lib and CLI just be calling it.

@GavinZZ
Copy link
Contributor

GavinZZ commented May 2, 2025

Thanks! This is a great feature to have!

I understand that we're detecting some kind of "diff" from a user point of view, but I'm very put-off by drift detection being part of cdk diff. That's just not what CDK diff historically did, and it's confusing to me. I wonder if it will be confusing to more people?

┌────────────┐            ╔═════════════╗            ┌────────────┐
│            │    diff    ║             ║    drift   │            │
│  Template  │◀──────────▶║    Stack    ║◀──────────▶│  Reality   │
│            │            ║             ║            │            │
└────────────┘            ╚═════════════╝            └────────────┘
                                                                   
                   ^                                               
               cdk diff                                            
            does this today                                        

Can we make this its own subcommand to begin with? cdk drift ?

@rix0rrr Let's discuss this further during Tuesday's meeting. While I'm open to making this a separate command, I'd like to explain my original reasoning for including it in cdk diff:

I envisioned cdk diff as a broader capability for detecting any differences affecting a deployed stack, whether those differences:

  • Come from changes in local CDK code
  • Result from manual modifications to deployed resources through console or CLI (Drifts)

However, I recognize your point about the historical context of cdk diff and the potential for user confusion. This would be a good topic for us to explore during the meeting, weighing the benefits of command consolidation against clarity and user expectations.

Leonardo Gama added 3 commits May 2, 2025 13:48
@rix0rrr
Copy link
Contributor

rix0rrr commented May 5, 2025

I envisioned cdk diff as a broader capability for detecting any differences affecting a deployed stack, whether those differences:

I see that, and I like the idea of a general cdk whatsup command.

There is some precedent for having certain features both as their own commands as well as options to other commands.

So I would propose to have both:

$ cdk drift
$ cdk diff --drift 

@mrgrain
Copy link
Contributor

mrgrain commented May 5, 2025

So I would propose to have both:

came here to say this. cdk drift should be the main command, cdk diff --drift is a convenience short cut.

@mrgrain mrgrain temporarily deployed to integ-approval May 27, 2025 13:27 — with GitHub Actions Inactive
@mrgrain mrgrain added this pull request to the merge queue May 27, 2025
Merged via the queue into aws:main with commit c48b685 May 27, 2025
21 checks passed
@mrgrain mrgrain self-assigned this May 27, 2025
github-merge-queue bot pushed a commit that referenced this pull request May 28, 2025
When we merged #442 we forgot to add message spans to the drift command.
This PR rectifies this.

Also contains a refactor of `MessageSpan` to be a separate class and to
represent itself as `IoHelper`. With that we can now pass a `Span` down
into subroutines and have those messages also emitted as part of the
span. Start using that in some places.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants