is it possible to log in to a state backend using ...
# automation-api
b
is it possible to log in to a state backend using the automation api?
Specifically I will be managing stacks across multiple gcp bucket state backends, so I want to be able to switch which backend I’m working with in code if possible
b
Yes you can use environments variables or project settings
b
Yep, I just got it working with project settings, but I noticed it will write
Pulumi.yaml
to the directory, overwriting any existing file. I’m attempting to drive an existing Pulumi project written in Python, with the Automation API from Go, and I will have stacks in different backends. Maybe my problem is that I’m mis-understanding the Project model. Should a Project only be tied to one backend?
l
No, it is possible to put different stacks in different backends, but I imagine that it's not a common model. Expect to have to do some experimentation to get it working fluidly.
b
Gotcha, I figured I may be wading into less familiar waters
b
If you are relying on your project files directory being static or something that is checked into source control than I would say yes, controlling backend at project level is probably easiest. But also automation api enables you to do your project setup transiently in code and not need to keep the project files around, so if you were doing that everytime you could allow automation api to spin that up in a temp directory that you don't care about and it would be a simple matter of providing the appropriate backend everytime you do the setup.
b
Yep, each backend here represents a different customer, and we want to hand them back the pulumi code we used to provision their resources, so I’m better off creating directory and writing the static
Pulumi.yaml
and then persist it.
Thanks @bored-oyster-3147 @little-cartoon-10569 for helping me rubber duck this
👍 1
l
For that model, I recommend a different approach.
I would put almost everything into external code (ComponentResource or similar), and have index.ts do almost nothing except grab values from Config and pass them into the external code.
Then provide a different project / repository per customer.
It will make auditing a lot simpler.
It is possible to have index.ts be very small, reducing the duplicate code.
It also means you can have multiple stacks per customer: dev and prod, for example 🙂
b
Ah yeah, I broke most of it up into a couple of major `ComponentResource`s already, I should just create a top level one to house everything
(and yeah pass any options through the config)