prehistoric-london-9917
06/01/2022, 11:59 PMasync
function), I get a weird behaviour where one of the providers seems to be trying to assume the wrong role.
I suspect it’s some sort of race condition where one of the threads gets to the provider first, assumes the right role, and is fine. Then the next thread comes along, but instead of a new provider, it’s using the original one, and I get STS errors about assuming the wrong role.
I suppose I can try waiting for each deployment to finish, but it’d be nice if they can run at the same time. Any thoughts?LocalWorkspaceOptions
interface like:
const opts: LocalWorkspaceOptions = {
secretsProvider: secretsProvider,
envVars: {
AWS_ACCESS_KEY_ID: credentials.Credentials!.AccessKeyId!,
AWS_SECRET_ACCESS_KEY: credentials.Credentials!.SecretAccessKey!,
AWS_SESSION_TOKEN: credentials.Credentials!.SessionToken!,
},
where credentials
is the output of an STS AssumeRoleCommand
action.
According to the docs, those environment variables should be passed to “every Pulumi command”.
However, when the automation runs:
const stack = await LocalWorkspace.createOrSelectStack(args, opts);
I get an access denied error on the bucket, which makes me think createOrSelectStack
is not using the environment variables as expected (though I’m not sure how to prove this).
If I set the process’ environment like I was originally (e.g. process.env.AWS_ACCESS_KEY_ID = xxx
) immediately before the createOrSelectStack
, it works as expected.
Any thoughts on how I can get createOrSelectStack
to honour the envVars
set in the opts
object?bored-oyster-3147
06/30/2022, 4:03 PMopts
. If that is not happening as expected than I would open an issue on github for it, as that is how it is supposed to function.