(core): Add source code relative file path to the CloudFormation template Metadata
See original GitHub issueDescription
Let’s take usermanagement-backend AWS CDK application as an example. It contains a pipeline that defines a production stage. The production stage contains a stateful stack with a database based on a DynamoDB table. Below is the metadata for the DynamoDB table synthesized for the above part of the application:
{
"Resources": {
"DatabaseTableF104A135": {
"Type": "AWS::DynamoDB::Table",
<snip>,
"Metadata": {
"aws:cdk:path": "UserManagementBackend-Pipeline/UserManagementBackend-Prod/Stateful/Database/Table/Resource"
}
},
},
<snip>
}
I would like to have the AWS CDK source code relative file path and line number included in the CloudFormation template Metadata section using a separate key (e.g. aws:cdk:code
). Here:
{
"Resources": {
"DatabaseTableF104A135": {
"Type": "AWS::DynamoDB::Table",
<snip>,
"Metadata": {
"aws:cdk:code": "database/infrastructure.py#L18"
"aws:cdk:path": "UserManagementBackend-Pipeline/UserManagementBackend-Prod/Stateful/Database/Table/Resource"
}
},
},
<snip>
}
Use Case
When I run cfn-nag/cfn-guard on a synthesized CloudFormation template, I need to find the AWS CDK source code that defines the related resource. It is difficult to find that source code based on the aws:cdk:path
metadata, because I need to follow construct IDs. This can be even more difficult if I use constants for parts of the construct ID name (e.g., application name as prefix for the stack). Having the source code file path and line number will save time on understanding and fixing issues reported by the aforementioned tools.
Proposed Solution
AWS CDK to add the source file path and line number to the CloudFormation template Metadata section during synthesis.
Other information
No response
Acknowledge
- I may be able to implement this feature request
- This feature might incur a breaking change
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (6 by maintainers)
Just had a chat w/ @alexpulver about this, and on the
jsii
side of things, it boils down to implementing https://github.com/aws/jsii/issues/47, or at least a sub-set of it:Error.captureStackTrace
to insert “artificial” frames received from the jsii API request object.Error.stackTraceLimit
across the language boundary to limit stack trace sizes to the user’s desired frame count.Jsii support for cross-language stack traces doesn’t necessarily entirely solve the problem at hand (but is probably necessary to achieve solutions):
Lazy
instance providers are evaluated during synthesis, often in a context that does not originate from outside of node. It might be necessary to capture the stack trace atLazy
creation time to provide all necessary context.In terms of next steps… I reckon we could start by prototyping this for Python (that work has to be prioritized before it can be started), and use this to validate whether this is sufficient to address the problem – in particular, it’ll be necessary to validate the assumption that starting with only “into node” stack trace continuity is sufficient for the majority use-case.
Commenting to keep this issue open