Skip to content
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

fix(cli): cdk ls returns stack id instead of stack display name #29447

Merged
merged 4 commits into from Mar 12, 2024

Conversation

SankyRed
Copy link
Contributor

@SankyRed SankyRed commented Mar 11, 2024

Issue # (if applicable)

Closes #29420

Reason for this change

The cdk list functionality displays the stacks .

For instance

> cdk ls
producer
consumer

With the latest changes for list stack dependencies we did add a new flag -d to show the dependencies.

The dependencies between stacks can be established in 2 ways:

  1. Using the resource defined from one stack in another.
  2. Using addDependency() to add dependency among stacks.

Current we are fetching the dependency details through the CloudStackArtifact.

  • Establishing the dependency between stacks through the first method would have the same displayName and id for the stacks.
    Using the -d flag to display dependencies -
❯ cdk list --show-dependencies
- id: producer
  dependencies: []
- id: consumer
  dependencies:
    - id: producer
      dependencies: []
  • Establishing the dependency through addDependency() will create a different displayName and id.
    In such a case when a user runs cdk ls we would want to show the displayName and if not present then use the id

For instance:

> cdk ls
producer
producer/consumer

With the -d flag we would want to display something like:

> cdk ls -d
- id: producer
  dependencies: []
- id: producer/consumer
  dependencies:
    - id: producer
      dependencies: []

With our previous change we didn't consider displayName and just fetched ids which changes the previous functionality and caused a regression.

Description of changes

With the new changes we are looking out for displayName first and if it does not exist we fetch the id.

Description of how you validated changes

Added a new unit test and updated integ tests.

Checklist


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

@github-actions github-actions bot added bug This issue is a bug. p0 labels Mar 11, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team March 11, 2024 20:13
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

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

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

@aws-cdk-automation aws-cdk-automation added the pr/needs-cli-test-run This PR needs CLI tests run against it. label Mar 11, 2024
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Mar 11, 2024
@vinayak-kukreja vinayak-kukreja added the pr/do-not-merge This PR should not be merged at this time. label Mar 11, 2024
@SankyRed SankyRed changed the title fix(cli): list stack fix when using addDependency to show displayName fix(cli): incorrect listing of stacks when using addDependency. Mar 11, 2024
@vinayak-kukreja vinayak-kukreja changed the title fix(cli): incorrect listing of stacks when using addDependency. fix(cli): cdk ls returns stack id instead of stack dispaly name Mar 11, 2024
@vinayak-kukreja vinayak-kukreja changed the title fix(cli): cdk ls returns stack id instead of stack dispaly name fix(cli): cdk ls returns stack id instead of stack display name Mar 11, 2024
@aws-cdk-automation
Copy link
Collaborator

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

@vinayak-kukreja vinayak-kukreja added pr-linter/exempt-integ-test The PR linter will not require integ test changes pr-linter/cli-integ-tested Assert that any CLI changes have been integ tested labels Mar 12, 2024
@aws-cdk-automation aws-cdk-automation dismissed their stale review March 12, 2024 01:35

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

@aws-cdk-automation aws-cdk-automation removed the pr/needs-cli-test-run This PR needs CLI tests run against it. label Mar 12, 2024
@SankyRed SankyRed removed the pr/do-not-merge This PR should not be merged at this time. label Mar 12, 2024
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 406e66c
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Copy link
Contributor

mergify bot commented Mar 12, 2024

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit 77189be into main Mar 12, 2024
14 of 15 checks passed
@mergify mergify bot deleted the SankyRed/list-stack-fix branch March 12, 2024 02:07
SankyRed added a commit that referenced this pull request Mar 12, 2024
…9447)

### Issue # (if applicable)

Closes #29420 

### Reason for this change

The `cdk list` functionality displays the stacks .

For instance
```
> cdk ls
producer
consumer
```
With the latest changes for list stack dependencies we did add a new flag `-d` to show the dependencies.

The dependencies between stacks can be established in 2 ways:
1. Using the resource defined from one stack in another.
2. Using `addDependency()` to add dependency among stacks.

Current we are fetching the dependency details through the `CloudStackArtifact`.

* Establishing the dependency between stacks through the first method would have the same `displayName` and `id` for the stacks.
Using the `-d` flag to display dependencies -

```
❯ cdk list --show-dependencies
- id: producer
  dependencies: []
- id: consumer
  dependencies:
    - id: producer
      dependencies: []
```
* Establishing the dependency through `addDependency()` will create a different `displayName` and `id`.
In such a case when a user runs `cdk ls` we would want to show the `displayName` and if not present then use the `id`

For instance:
```
> cdk ls
producer
producer/consumer
```
With the `-d` flag we would want to display something like:
```
> cdk ls -d
- id: producer
  dependencies: []
- id: producer/consumer
  dependencies:
    - id: producer
      dependencies: []
```
With our previous change we didn't consider `displayName` and just fetched `id`s which changes the previous functionality and caused a regression.

### Description of changes

With the new changes we are looking out for `displayName` first and if it does not exist we fetch the `id`.

### Description of how you validated changes

Added a new unit test and updated integ tests.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*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
bug This issue is a bug. contribution/core This is a PR that came from AWS. p0 pr-linter/cli-integ-tested Assert that any CLI changes have been integ tested pr-linter/exempt-integ-test The PR linter will not require integ test changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

❗ NOTICE: List stack output change issue.
4 participants