https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
m
Ahh yes, but this still fails because the default provider has a 
profile
and env vars don't override profile any more.
I've resorted to using this command in CI before `up`:
Copy code
pulumi config rm aws:profile
l
We do the opposite. Require that aws:profile is always set. Lint rule to check the stack file. Disable default provider, pass provider everywhere. And when constructing providers, always provide 
profile: awsConfig.require("profile");
And if we need to change the profile for an environment, we do that in the build script or whatever, before calling Pulumi.
m
"pass provider everywhere" The part I hate 😞
That said, it's probably the better strategy long-term
The other downside of using an AWS profile in CI is that the secrets would be written to disk
l
I'm a big fan of being OTT explicit. Allowing people to guess providers isn't convention-over-configuration, it's just making it easier to hide bugs..
Our AWS profiles only ever contain session creds, max duration an hour. We often have "permanent" profiles, but they use role_arn and source_profile. The base profiles are always temporary creds.
And we use OIDC for our CI-initiated deployments. That was great, when GitHub announced that.
m
Yeah, I think long-term it's the best strategy given the default provider being tightly coupled with the Stack config. The problem isn't even the verbosity, but the cases where we have abstractions that will make passing the explicit provider a bigger chore.
Your setup sounds similar to ours
l
We have a base library that builds AWS providers for us, based on things like well-known account IDs and stack names. We construct providers wherever needed.
m
Ahh, interesting. We have similar, for helpers and custom component resource definitions (
pulumi-components
).
3 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by