chore(core): update CDK Metadata to report construct-level details #13423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See CDK RFC 253 (aws/aws-cdk-rfcs#254) for background and details. Currently -- if a user has not opted out -- an AWS::CDK::Metadata resource is added to each generated stack template with details about each loaded module and version that matches an Amazon-specific allow list. This modules list is used to: - Track what library versions customers are using so they can be contacted in the event of a severe (security) issue with a library. - Get business metrics on the adoption of CDK and its libraries. This modules list is sometimes inaccurate (a module may be loaded into memory without actually being used) and too braod to support CDK v2. This feature implements (mostly) the specification proposed in RFC 253 to include metadata about what constructs are present in each stack, rather than modules loaded into memory. The allow-list is still used to ensure only CDK/AWS constructs are reported on. Implementation notes: - The format of the Analytics property has changed slightly since the RFC. See the service-side code for justification and latest spec. - How to handle the jsii runtime information was left un-spec'd. I've chosen to create a psuedo-Construct to add to the list as the simplest solution. - `runtime-info.test.ts` leaps through some serious hoops to work equally well for both v1 and v2, and to fail somewhat gracefully locally if `tsc` was used to compile the module instead of `jsii`. Critques of this approach welcome! - I removed an annoyance from `resolve-version-lib.js` that produced error messages when running unit tests.
njlynch
added
the
pr-linter/exempt-readme
|
|
|
I feel this ought to be a |
rix0rrr
previously requested changes
Mar 8, 2021
njlynch
changed the title
eladb
approved these changes
Mar 9, 2021
|
added |
njlynch
removed
pr/do-not-merge
njlynch
dismissed
rix0rrr’s stale review
Comments addressed; confirmed offline.
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
eladb
approved these changes
Mar 10, 2021
| * 1.90.0!aws-cdk-lib.{Stack,Construct,service.Resource},0.42.1!aws-cdk-lib-experiments.NewStuff | ||
| * | ||
| * The whole thing is then either included directly as plaintext as: | ||
| * v2:plaintext:{prefixEncodedList} |
There was a problem hiding this comment.
Suggested change
| * v2:plaintext:{prefixEncodedList} |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See CDK RFC 253 (aws/aws-cdk-rfcs#254) for background and details.
Currently -- if a user has not opted out -- an AWS::CDK::Metadata resource
is added to each generated stack template with details about each loaded module
and version that matches an Amazon-specific allow list.
This modules list is used to:
the event of a severe (security) issue with a library.
This modules list is sometimes inaccurate (a module may be loaded into memory
without actually being used) and too braod to support CDK v2.
This feature (mostly) implements the specification proposed in RFC 253 to
include metadata about what constructs are present in each stack, rather than
modules loaded into memory. The allow-list is still used to ensure only CDK/AWS
constructs are reported on.
Implementation notes:
the service-side code for justification and latest spec.
create a psuedo-Construct to add to the list as the simplest solution.
runtime-info.test.tsleaps through some serious hoops to work equally wellfor both v1 and v2, and to fail somewhat gracefully locally if
tscwas usedto compile the module instead of
jsii. Critques of this approach welcome!resolve-version-lib.jsthat produced errormessages when running unit tests.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license