-
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
(cli): Cross-account asset publishing broken in v1.135 #17988
Labels
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
package/tools
Related to AWS CDK Tools or CLI
Comments
This appears to be happening on |
I encounter the same problem. The v |
rix0rrr
added a commit
that referenced
this issue
Dec 14, 2021
In #17668, cross-account S3 asset publishing was broken. The reason is that the `account()` function was always broken, using the default account instead of the target account. However, previously this function was only called in an irrecoverable situation anyway, and its failure would be rare. The recent change also calls this function for logging purposes in a happy-case scenario, but then triggers an error during the logging. Fix the invocation to use the right account. Fixes #17988.
mergify bot
pushed a commit
that referenced
this issue
Dec 14, 2021
In #17668, cross-account S3 asset publishing was broken. The reason is that the `account()` function was always broken, using the default account instead of the target account. However, previously this function was only called in an irrecoverable situation anyway, and its failure would be rare. The recent change also calls this function for logging purposes in a happy-case scenario, but then triggers an error during the logging. Fix the invocation to use the right account. Fixes #17988. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
TikiTDO
pushed a commit
to TikiTDO/aws-cdk
that referenced
this issue
Feb 21, 2022
In aws#17668, cross-account S3 asset publishing was broken. The reason is that the `account()` function was always broken, using the default account instead of the target account. However, previously this function was only called in an irrecoverable situation anyway, and its failure would be rare. The recent change also calls this function for logging purposes in a happy-case scenario, but then triggers an error during the logging. Fix the invocation to use the right account. Fixes aws#17988. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
package/tools
Related to AWS CDK Tools or CLI
What is the problem?
CDK asset publishing doesn't correctly assume the target asset publishing role in certain cases and fails to deploy S3 artifacts.
The issue seems to have surfaced with the release of cdk 1.135.0 but was possibly introduced in earlier versions.
Initial investigation suggests this line isn't passing the stack's asset publishing role and instead making API calls as the base role.
When v1.135 is used to deploy against an account bootstrapped with stack
< v9
, this code branch will trigger the aboveaccount()
call which causesthis.host.aborted
to becometrue
and this line to never be reached.Reproduction Steps
AccountA
AccountB
with stack v8 ( cdk <= 1.134.0 ), and--trust
role inAccountA
AccountB
@aws-cdk/core:newStyleStackSynthesis
=true
What did you expect to happen?
CDK deploy assumes the asset publishing role in
AccountB
and correctly uploads artifactsWhat actually happened?
fail: Need to perform AWS calls for account <AccountB>, but the current credentials are for <AccountA>
CDK CLI Version
1.135.0
Framework Version
No response
Node.js Version
v14.16.0
OS
MacOS
Language
Typescript
Language Version
No response
Other information
Complete deploy log:
The text was updated successfully, but these errors were encountered: