question - we recently had to upgrade to `pulumi-a...
# aws
question - we recently had to upgrade to
one thing we’re noticing is when executing pulumi from CI/CD, our runners didn’t need things like:
Copy code
to explicitly need the aws provider or role to assume to function — it used to fall back to the default profile in the stack and assume the default profile’s role. Now we’re seeing that the pulumi_aws methods are attempting (and failing) to run w/o assuming the default profile. is there a graceful way for us to opt into that old functionality w/o going and passing the provider explicitly in all method calls?
man i’m not really sure how this worked previously, now that I’m reading this. i guess the TF docs are talking more about the provider specifically; i’m running into cases where i had multiple cases of
calls w/o a provider or parent passed into it, and it just worked
so, we actually have
in each stack’s config….hmm
ok maybe to rephrase this word spaghetti better it looks like, prior to upgrading (~
), our project relied on the default aws provider to do its thing. so, we never needed to pass any named provider, bc the default provider was in scope at some point, after going to
, this default provider basically disappeared from the execution context, even though we have all the env vars and
still in scope + unchanged
update: it’s the terraform authentication order thing. had to remove