-
Notifications
You must be signed in to change notification settings - Fork 4k
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
(core): Add support for suppressing Annotation messages #23403
Comments
This is an excellent idea that's been in the back of my mind as well. The flat option should be simple enough to implement. |
Here is my design for this feature, I don't have time to implement it but maybe someone else will. The steps are:
1. addWarning gets an extra key Annotations.of(this.queue).addWarning('whatever the message', {
suppressionKey: 'max-visibility',
}); 2. Warnings can be suppressed from code Annotations.of(this.queue).suppressWarning(
'max-visibility',
'something-else',
); Will suppress all warnings underneath the indicated construct, with the given key. It should work before and after the construct has been added to the tree (so 3. Warnings can be suppressed from context// cdk.json
{
"app": "ts-node ...",
"context": {
"suppress:/Stack/Construct/Queue:max-visibility
}
} Effect should be the same as putting |
Potentially there's a key |
I like your idea @rix0rrr What do you think about automatically generating the suppression key? I'm thinking like how resource id's are generated (logical/physical). Then we could add to the Annotation logging to include that key Also, we should probably have some sort of toggle for Construct owners to enable/disable an annotation from being suppressed. |
I believe this is implemented now with Warning:
Suppression:
|
Yeah, it does seem like we've solved the problem with #26144 :D |
|
Describe the feature
The idea here would be to create a commitable lock file of generated annotations, a similar concept to NPM's
pacakge-lock.json
.Use Case
Proposed Solution
When this lock file is committed, then we would no longer print out the warning in the console. If the
annotation
,level
orscope
have changed, then that would render the locked annotation out of date and would no longer suppress the message (We could probably do this with some base64 encoding?)Flat option:
Nested Option:
I purposefully use
jsonc
here to ensure users know they can put comments in the lock file. That way, if you wanted to create a task or backlog item in a ticketing system you could reference it here.Other Information
This is definitely just an idea that I thought of after using CDK for the past year or so, with a particularly noisy construct library. Absolutely open to discussion/thoughts on the idea or if there are better ways to do this.
Acknowledgements
CDK version used
2.55.1
Environment details (OS name and version, etc.)
OS independant
The text was updated successfully, but these errors were encountered: