feat: sdkv3 upgrade for CLI (wip)#31624
Conversation
aws-cdk-automation
left a comment
There was a problem hiding this comment.
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.
78798f5 to
fd34c5c
Compare
| // ECS and EKS instances also run on EC2 boxes but the creds represent something different. | ||
| // Same behavior as upstream code. | ||
| sources.push(() => new AWS.EC2MetadataCredentials()); | ||
| return fromIni({ |
There was a problem hiding this comment.
Currently, SSO has precedence over process, but in fromIni, it's the other way around. It's highly unlikely that someone mistakenly configures both, but I think we should keep the current behavior.
There was a problem hiding this comment.
So, fromIni actually covers SSO in v3. It didn't work with V2, which is why we manually put it ahead of Ini.
There was a problem hiding this comment.
Sure, but we are changing the behavior now. If someone has both credential_process and sso_* set in their config file, the current version of the CLI will use the SSO credentials. With this change, after they upgrade, the CLI will start using the process credentials. Maybe this is ok, but but we need at least to document this somewhere.
| return shouldPrioritizeEnv() | ||
| ? createCredentialChain(fromEnv(), nodeProviderChain).expireAfter(60 * 60_000) | ||
| : nodeProviderChain; | ||
| } |
There was a problem hiding this comment.
[feedback on readability] when I was reviewing this, I found it a bit hard to follow how the env variables fit into the chain. It's surprising to see a method whose name starts with "should" that modifies environment variables, that then gets picked up by fromEnv() (or not).
I suggest we implement our own provider that reads from both AWS_* and AMAZON_* sets of variables. And this provider is always put at the beginning of the chain. Up to you.
| // we can determine whether the AssumeRole call succeeds or not. | ||
| try { | ||
| await sdk.forceCredentialRetrieval(); | ||
| // Force retrieval here |
There was a problem hiding this comment.
We can remove this whole try-catch now, can't we?
There was a problem hiding this comment.
Yes. Removing it.
| config: { | ||
| 'profile ecs': { role_arn: 'arn:aws:iam::12356789012:role/Assumable', credential_source: 'EcsContainer', $account: '22222' }, | ||
| // GIVEN | ||
| const calls = jest.spyOn(console, 'debug'); |
There was a problem hiding this comment.
Shouldn't we be using the mocked metadata service?
| * SDK, so we pretend to be the STS server and have an in-memory database | ||
| * of users and roles. | ||
| * | ||
| * With the v3 upgrade, this is only now half way being used as |
There was a problem hiding this comment.
I died half way though writing this comment. There is no way of knowing the ending.
But also, the "as" is that the mock sdk client made some of it unnecessary. I'll fix this comment to clarify.
There was a problem hiding this comment.
Instead of deleting these tests, can't we keep them and use a mocked STS and a mocked token file?
There was a problem hiding this comment.
I don't know why it's outdated, but the question still applies.
There was a problem hiding this comment.
The reason I deleted these instead of trying to rewrite them is that previously we wrote our own functionality for whether or not to call these, now we're just using the credential provider that the sdk provides so we'd essentially be unit testing their code, not ours.
| name: 'mock', | ||
| }; | ||
|
|
||
| const templateBody = toYAML(deserializeStructure(serializeStructure(legacyBootstrapTemplate({}), true))); |
There was a problem hiding this comment.
What's the difference between this and:
const templateBody = serializeStructure(legacyBootstrapTemplate({}), false);
?
There was a problem hiding this comment.
This is silly looking but unfortunately necessary. If we only serialize it, the template body isn't formatted correctly due to the escape characters that get added in. If we skip the deserialization/serialization part and just do toYAML, we get the same output.
fd34c5c to
54a35cf
Compare
54a35cf to
8f7b25c
Compare
otaviomacedo
left a comment
There was a problem hiding this comment.
We should also add some CLI integration tests for the credential loading scenarios.
66ed30f to
723afa7
Compare
723afa7 to
f56fe7f
Compare
…ns (#31658) #31624 is too big so I'm splitting out the parts that I can without causing type conflicts. This upgrades all sdk v3 versions to the most recent version used in every region by lambda's node18 and node20 runtime bundle. Closes #<issue number here>. ### Reason for this change ### Description of changes ### Description of how you validated changes ### Checklist - [ ] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
f56fe7f to
4acc721
Compare
16ffad3 to
714b314
Compare
714b314 to
de3c43d
Compare
de3c43d to
9b9c312
Compare
9b9c312 to
c36eb47
Compare
|
This is succeeding in our build pipeline but not in the PR Build. What in the world is going on. |
e46a6ca to
3bb1c21
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
➡️ PR build request submitted to A maintainer must now check the pipeline and add the |
Working on it! |
|
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 |
|
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #.
Reason for this change
Description of changes
Description of how you validated changes
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license