chore: make tests work with new SDKv3 version #33016
Conversation
In a recent upgrade of the SDKv3, the INI credential provider has gotten a private copy of the STS Client, to make AssumeRole calls with. This means the STS Client used by the INI provider is now unmockable. In #31702, we migrated the tests of the credentials chain mostly to using mocks, as opposed to what it was doing in the past: intercepting network traffic and emulating a fake STS Endpoint. These tests now start failing due to an SDK upgrade. Fortunately, most of the old code was still there, so in this change I'm ripping out the STS Mocking and doing a couple minor changes; the tests now pass again.
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
| "@aws-sdk/credential-providers": "3.699.0", | ||
| "@aws-sdk/ec2-metadata-service": "3.699.0", | ||
| "@aws-sdk/lib-storage": "3.699.0", | ||
| "@aws-sdk/client-appsync": "^3.699.0", |
There was a problem hiding this comment.
Not super important but I think our package.json normally corresponds with the lock file.
| "@aws-sdk/client-appsync": "^3.699.0", | |
| "@aws-sdk/client-appsync": "^3.730.0", |
There was a problem hiding this comment.
Sorta the point of having the distinction between a package.json and a lockfile?
I do not care about this 😉
|
@rix0rrr this also upgrades the SDK version, mention it in the PR title? |
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
rix0rrr
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #33016 +/- ##
==========================================
+ Coverage 81.44% 81.46% +0.02%
==========================================
Files 225 225
Lines 13750 13750
Branches 2412 2412
==========================================
+ Hits 11198 11202 +4
+ Misses 2277 2273 -4
Partials 275 275
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
Comments on closed issues and PRs are hard for our team to see. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
3 participants
In a recent upgrade of the SDKv3, the INI credential provider has gotten a private copy of the STS Client, to make AssumeRole calls with. This means the STS Client used by the INI provider is now unmockable.
In #31702, we migrated the tests of the credentials chain mostly to using mocks, as opposed to what it was doing in the past: intercepting network traffic and emulating a fake STS Endpoint. These tests now start failing due to an SDK upgrade.
Fortunately, most of the old code was still there, so in this change I'm ripping out the STS Mocking and doing a couple minor changes; the tests now pass again.
This PR also upgrades the SDKv3 version at the same time, some other packages that needed to be upgraded along with this as well (
@smithy/middleware-endpointandcdk-assetswhich covers a new enum value for the S3 client).By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license