-
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
fix(cfn-include): cfn-include fails in monocdk #11595
Conversation
I unfortunately only tested this change manually. I tried adding a simple unit test for @nija-at let me know if this solution makes sense. If yes, we can also add it to the |
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.
We need to identify a way to test this. We can't afford for this to regress if we decide to change something in aws-cdk-lib
and it breaks cfn-include again.
Can we add an integration test instead?
@nija-at let me know if this solution makes sense. If yes, we can also add it to the aws-cdk-lib package on the v2-main branch.
Add it into the aws-cdk-lib
package in master
and it will automatically get merged into v2-main
d7353d9
to
fe4e907
Compare
@nija-at after some digging and trail-and-error, I was able to add a unit test in monocdk that correctly checks this (I looked into an integration test, but it looked very painful). Let me know if this solution works for you! |
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.
Can we move this into a separate package under the tools/
folder so that it can be reused across monocdk
and aws-cdk-lib
?
ubergen
might be a good spot but would be nice to have a separate one so it's kept separate and decoupled.
9da4ce9
to
99c4666
Compare
99c4666
to
ac3ed43
Compare
This has been done. @nija-at please take another look! |
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 this point, this discussion is likely more effective and faster to converge synchronously.
ac3ed43
to
1d60f92
Compare
@nija-at I've re-structured the solution completely, by moving the logic of re-writing the file to |
1d60f92
to
ef41589
Compare
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.
Much better set of changes than the previous iteration. Thanks for taking the time to fix this.
These comments are less intrusive.
The cloudformation-include module generates a big JSON file at build time that contains the mapping from the CloudFormation resource type to the fully-qualified class name of the corresponding L1 (something like "AWS::S3::Bucket": "@aws-cdk/aws-s3.CfnBucket"). The problem is that mono-CDK re-packages all of the per-service modules into one big module, and requiring the module from the mapping fails for it. Solve the issue by adding an additional build step in ubergen that re-writes that file with the mapping values changed (to something like "monocdk/aws-s3.CfnBucket"). Fixes aws#11342
ef41589
to
8c3ad08
Compare
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.
LGTM! Some minor comments below.
You will need to make changes to cdk-ops to add this integration test for monocdk
to cdk-master
and aws-cdk-lib
to v2-main
.
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). |
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). |
The changes from #11595 moved some helper TypeScript files around. When running without compiling first (like in the pipeline, or in the canaries), we need to install the dependencies those files need manually. Unfortunately, after the move, they are now installed in a sibling directory, not in any ancestor directory, and so `require`ing them fails.
…tor (#12029) The changes from #11595 moved some helper TypeScript files around. When running without compiling first (like in the pipeline, or in the canaries), we need to install the dependencies those files need manually. Unfortunately, after the move, they are now installed in a sibling directory, not in any ancestor directory, and so `require`ing them fails. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The cloudformation-include module generates a big JSON file at build time that contains the mapping from the CloudFormation resource type to the fully-qualified class name of the corresponding L1 (something like "AWS::S3::Bucket": "@aws-cdk/aws-s3.CfnBucket"). The problem is that mono-CDK re-packages all of the per-service modules into one big module, and requiring the module from the mapping fails for it. Solve the issue by adding an additional build step in mono-CDK that re-writes that file with the mapping values changed (to something like "monocdk/aws-s3.CfnBucket"). Fixes aws#11342 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…tor (aws#12029) The changes from aws#11595 moved some helper TypeScript files around. When running without compiling first (like in the pipeline, or in the canaries), we need to install the dependencies those files need manually. Unfortunately, after the move, they are now installed in a sibling directory, not in any ancestor directory, and so `require`ing them fails. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
When we did the changes to fix cloudformation-include in aws#11595, we did not account for the fact that the `@aws-cdk/core` is not mapped to `uberpackage/core`, but instead just to the `uberpackage` root namespace. Special-case the `@aws-cdk/core` module in ubergen when transforming the `cfn-types-2-classes.json` file.
When we did the changes to fix cloudformation-include in #11595, we did not account for the fact that the `@aws-cdk/core` is not mapped to `uberpackage/core`, but instead just to the `uberpackage` root namespace. Special-case the `@aws-cdk/core` module in ubergen when transforming the `cfn-types-2-classes.json` file. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…12758) When we did the changes to fix cloudformation-include in aws#11595, we did not account for the fact that the `@aws-cdk/core` is not mapped to `uberpackage/core`, but instead just to the `uberpackage` root namespace. Special-case the `@aws-cdk/core` module in ubergen when transforming the `cfn-types-2-classes.json` file. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The cloudformation-include module generates a big JSON
file at build time that contains the mapping from the CloudFormation resource type
to the fully-qualified class name of the corresponding L1
(something like "AWS::S3::Bucket": "@aws-cdk/aws-s3.CfnBucket").
The problem is that mono-CDK re-packages all of the per-service
modules into one big module,
and requiring the module from the mapping fails for it.
Solve the issue by adding an additional build step in mono-CDK that re-writes that file with the mapping values changed
(to something like "monocdk/aws-s3.CfnBucket").
Fixes #11342
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license