feat: add drift detection to cdk as cdk drift

[Leo10Gama]

Fixes # N/A

Added an additional command, 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:

With no resources drifted: (image outdated)

---

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

[rix0rrr]

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.

[mrgrain]

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]

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.

[rix0rrr]

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]

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]

this seems like it's doing nothing?

[Leo10Gama]

It's meant to give a brief half-second delay between iterations. Without this, it overflows the debug output with messages every chance it gets

[mrgrain]

Can this be outside the loop?

[Leo10Gama]

I don't believe so, since this will do the drift detection on each stack in the names provided.