-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(apigateway): deployment not invalidated when integration is changed #4552
Conversation
The calculation of the deployment logical id is based on a hash of the apigateway model, which includes components such as the resource and method configurations. method integrations, which are part of the method configuration are also included, and could possible include references to other resources such as lambda functions. When the hash was calculated, tokens have been resolved using `StringConcat` which basically converted all tokens to `[Object object]`. This means, for example, that if we changed the reference of an integration lambda to a different handler, the hash would remain the same. There is no apparent reason why we can't simply resolve tokens using the CloudFormation concatenation function during "prepare", which means that if we now reference a different resource, the token will resolve to a different value and deployment will be invalidated. Fixes #4551 Fixes aws-samples/aws-cdk-intro-workshop#83
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 |
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 |
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 think you are correct that there is no reason we can't do this...
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 |
Thank you for contributing! Your pull request is now being automatically merged. |
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 |
The calculation of the deployment logical id is based on a hash of the apigateway model, which includes components such as the resource and method configurations. method integrations, which are part of the method configuration are also included, and could possible include references to other resources such as lambda functions.
When the hash was calculated, tokens have been resolved using
StringConcat
which basically converted all tokens to[Object object]
. This means, for example, that if we changed the reference of an integration lambda to a different handler, the hash would remain the same.There is no apparent reason why we can't simply resolve tokens using the CloudFormation concatenation function during "prepare", which means that if we now reference a different resource, the token will resolve to a different value and deployment will be invalidated.
Fixes #4551
Fixes aws-samples/aws-cdk-intro-workshop#77
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license