-
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
feat: publish construct hierarchy with metadata to cloud assembly #4194
Conversation
Publish the CDK construct hierarchy with the construct id and path to the cloud assembly directory, with a corresponding manifest entry. Motivation and proposal documented in RFC - #4053. This change focuses on integrating generating the metadata into the cloud assembly as part of the the 'synthesize' lifecycle phase. Subsequent changes will enrich the metadata file with additional information from the construct tree (see RFC).
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
Add an example output in the PR description
Note, the inclusion of a BREAKING CHANGE in the PR description. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
* Rename ConstructTreeMetadata to Tree * Wrap tree construct with a version number * Move Tree construct into the constructor
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
||
/** | ||
* Include construct tree metadata as part of the Cloud Assembly. | ||
* |
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.
Add a "@see" with a link to the RFC
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.
Sure. I'll wait until the RFC is published so I can get the a more stable link.
* Renamed Tree to TreeMetadata * Re-typed 'metadata' to 'tree' in CloudArtifacts
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
@@ -80,7 +84,8 @@ export class CloudArtifact { | |||
switch (artifact.type) { | |||
case ArtifactType.AWS_CLOUDFORMATION_STACK: | |||
return new CloudFormationStackArtifact(assembly, id, artifact); | |||
|
|||
case ArtifactType.CDK_TREE: | |||
return new TreeCloudArtifact(assembly, id, artifact); | |||
default: | |||
throw new Error(`unsupported artifact type: ${artifact.type}`); |
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.
IMPORTANT: Just realized that this change requires a bump in the cx-protocol version because we were stupid enough to throw an error when reading a cloud assembly with unrecognized artifact types (no future compatibility). This means that an old CLI will crash if it will try to synth a CDK app that has this change.
Please also remove this default:
section and simply ignore unknown artifacts. That should be the correct behavior going forward so we can avoid such issues.
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.
At least make it a warning or something right. Not srue that ignoring is the right behavior.
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 warning should say something like "Unrecognized artifact type: ${type}. You need to upgrade your CDK CLI to use this artifact" or something. Give users a hint on how to remedy this.
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.
I don't think it makes total sense to issue a warning from this library. Maybe the CLI can issue a warning if this returns undefined
Since we've added a new type of artifact to the cloud assembly, namely CDK_TREE, the protocol version needs to be bumped. This will result in CDK customers being notified to upgrade the CDK CLI to >= 1.10.0. To prevent this from occurring in the future, the change also changes the behaviour when an unknown artifact type is detected when reading the cloud assembly manifest. This ensures that the CLI will be forwards compatible to cloud assemblies when new artifact types are added to them. See #4194 (comment)
Since we've added a new type of artifact to the cloud assembly, namely CDK_TREE, the protocol version needs to be bumped. This will result in CDK customers being notified to upgrade the CDK CLI to >= 1.10.0. To prevent this from occurring in the future, the change also changes the behaviour when an unknown artifact type is detected when reading the cloud assembly manifest. This ensures that the CLI will be forwards compatible to cloud assemblies when new artifact types are added to them. See #4194 (comment)
Since we've added a new type of artifact to the cloud assembly, namely CDK_TREE, the protocol version needs to be bumped. This will result in CDK customers being notified to upgrade the CDK CLI to >= 1.10.0. To prevent this from occurring in the future, the change also changes the behaviour when an unknown artifact type is detected when reading the cloud assembly manifest. This ensures that the CLI will be forwards compatible to cloud assemblies when new artifact types are added to them. See aws#4194 (comment)
Publish the CDK construct hierarchy with the construct id and path to
the cloud assembly directory, with a corresponding manifest entry.
Motivation and proposal documented in RFC - #4053.
This change focuses on integrating generating the metadata into the
cloud assembly as part of the the 'synthesize' lifecycle phase.
Subsequent changes will enrich the metadata file with additional
information from the construct tree (see RFC).
BREAKING CHANGES:
environment
is no longer a property ofCloudArtifact
, instead is a property of its subclass -CloudformationArtifact
.construct.node.setContext()
no longer works on theApp
construct. UseAppProps
instead to pass context values.The following CDK app generates the subsequent tree metadata JSON file
CDK app:
Construct tree JSON:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license