-
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
chore(cdk): add sdkv3 support to sdk.ts #31501
base: main
Are you sure you want to change the base?
Conversation
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 pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
lambda(): Lambda; | ||
cloudFormation(): CloudFormation; | ||
ec2(): EC2; | ||
iam(): IAM; | ||
ssm(): SSM; | ||
s3(): S3; | ||
route53(): Route53; | ||
ecr(): ECR; | ||
ecs(): ECS; | ||
elbv2(): ElasticLoadBalancingV2; | ||
secretsManager(): SecretsManager; | ||
kms(): KMS; | ||
stepFunctions(): SFN; | ||
codeBuild(): CodeBuild; | ||
cloudWatchLogs(): CloudWatchLogs; | ||
appsync(): AppSync; |
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.
Let's not change any of these methods for now. Create new ones, that return the corresponding service client (e.g., S3Client
) and incrementally switch to these new methods. Once no one is using the old methods anymore, we delete them.
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.
Donezo
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.
actually I realized I took a different approach to the one you described. I just created a completely updated SDKv3
class with all of the services upgraded to v3 and then left the original SDK
class unchanged.
My thought was that when migrating something which depends on SDK
we'd swap it to SDKv3
and then when everything is swapped over we delete the original and rename SDKv3
to SDK
Let me know if you think this approach isn't as effective and if you'd just rather see me keep the same class and then we swap out services out one at a time every time we update a file.
The pull request linter fails with the following errors:
PRs must pass status checks before we can provide a meaningful review. If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Reason for this change
Adding support for the SDKv2 to v3 migration in the cdk
Description of changes
Created copies of the SDK and ISDK classes with v3 support. Future migration efforts involving this class should use SDKv3. Once everything is migrated we will delete the original implementation and rename v3 to just
SDK
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license