-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat(assertions): add stack tagging assertions #27633
Conversation
There was a problem hiding this 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.
Exemption Request As far as I can tell, the assertions library does not have integration tests, but I'm happy to be corrected. |
@SankyRed thanks for picking this up. As far as I know there's nothing more I can do before review: tests pass and I don't think integration tests are required (see the exemption request). Have I missed something that would allow a review? |
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
Adds a Tag class to the assertions library that permits assertions against tags on synthesized CDK stacks.
I've rebased this PR on the latest |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error. |
The pull request linter fails with the following errors:
PRs must pass status checks before we can provide a meaningful review. If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing |
Adds a `Tag` class to the assertions library that permits assertions against tags on synthesized CDK stacks. Tags on AWS resources can be checked via assertions with the Template class, but since stack tags only appear on the cloud assembly manifest as a sibling of the template, a separate assertion mechanism is required. > [!NOTE] > Previously submitted as #27633, which was closed automatically while waiting for review. > > This PR is complete to the best of my knowledge, needing only an exemption from integration tests. As far as I can tell, this area of the library has no integration tests directly associated. ### API ```ts class Tags { public static fromStack(stack: Stack) : Tags; public hasValues(props: any): void; public all(): { [key: string]: string }; } ``` ### Usage This new class permits tests of the form: ```ts import { App, Stack } from 'aws-cdk-lib'; import { Tags } from 'aws-cdk-lib/assertions'; const app = new App(); const stack = new Stack(app, 'MyStack', { tags: { 'tag-name': 'tag-value' } }); const tags = Tags.fromStack(stack); // using a default 'objectLike' Matcher tags.hasValues({ 'tag-name': 'tag-value' }); // or another Matcher tags.hasValues({ 'tag-name': Match.anyValue() }); ``` You can also get the set of tags to test them in other ways: ```ts tags.all() ``` ## Issues ### No tags case One might expect that the case where no tags are present would match `undefined` or `null`, but since the Cloud Assembly API defaults tags to `{}` when none are present, this isn't possible. It's also not practical to directly test the `artifact.manifest.properties.tags` value directly, as there is a legacy case that the API handles. This means that the `artifact.tags` property is the best value to check against. The tests for this PR show that matching with `Match.absent()` will fail when there are no tags, but testing against the empty object will succeed. I think that this behaviour (defaulting to empty) will be OK, but potentially require a callout on the assertion method. ### API method naming The current suggested API went through some evolution, starting with: ```ts class Tags { public static fromStack(stack: Stack) : Tags; public hasTags(props: any): void; public getTags(): { [key: string]: string }; } ``` But this stuttered, and `getTags()` wasn't compatible with Java. I considered: ```ts class Tags { public static fromStack(stack: Stack) : Tags; public hasValues(props: any): void; public values(): { [key: string]: string }; } ``` and ```ts class Tags { public static fromStack(stack: Stack) : Tags; public has(props: any): void; public all(): { [key: string]: string }; } ``` ... before settling on a mix of the two. I think the current iteration fits with the rest of the `assertions` API and makes sense by itself, but very open to changes. Closes #27620. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Adds a
Tag
class to the assertions library that permits assertions against tags on synthesized CDK stacks.Tags on AWS resources can be checked via assertions with the Template class, but since stack tags only appear on the cloud assembly manifest as a sibling of the template, a separate assertion mechanism is required.
API
Usage
This new class permits tests of the form:
You can also get the set of tags to test them in other ways:
Issues
No tags case
One might expect that the case where no tags are present would match
undefined
ornull
, but since the Cloud Assembly API defaults tags to{}
when none are present, this isn't possible. It's also not practical to directly test theartifact.manifest.properties.tags
value directly, as there is a legacy case that the API handles. This means that theartifact.tags
property is the best value to check against.The tests for this PR show that matching with
Match.absent()
will fail when there are no tags, but testing against the empty object will succeed.I think that this behaviour (defaulting to empty) will be OK, but potentially require a callout on the assertion method.
API method naming
The current suggested API went through some evolution, starting with:
But this stuttered, and
getTags()
wasn't compatible with Java.I considered:
and
... before settling on a mix of the two. I think the current iteration fits with the rest of the
assertions
API and makes sense by itself, but very open to changes.Closes #27620.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license