https://pulumi.com logo
#getting-started
Title
# getting-started
t

thousands-knife-3009

02/21/2024, 2:45 PM
When setting up pulumi to run solely from a gitlab ci/cd stage, how do you handle the stack config file? i'm using a gcp bucket for my backend and want stacks created/used in ci/cd based on the branch executing the job.
s

salmon-account-74572

02/21/2024, 3:01 PM
For long-lived stacks, you'll generally check the stack configuration file into source control. Then, in your CI job, you run
pulumi stack select <stack>
based on the branch. Or are you looking to have some sort of ephemeral stack-like functionality, where stacks are created dynamically and removed later?
t

thousands-knife-3009

02/21/2024, 3:05 PM
I'm hoping to get something more long lived but dynamic. I don't want to have to run pulumi commands locally before setting up the project.
If I don't include Pulumi.<stack>.yaml in my repository and have all the required values set in Pulumi.yaml or environment variables will it work ok? Would I need to run stack init on every build/run or would it detect the stack already exists in the backend?
s

salmon-account-74572

02/21/2024, 3:13 PM
If your Pulumi stack configuration files are checked into source control, you won't need to run
pulumi stack init
and set configuration values, but you will need to run
pulumi stack select <stack-name>
to tell the CI job which stack you're using. Does that help?
t

thousands-knife-3009

02/21/2024, 3:14 PM
what if i don't have a Pulumi.<stack>.yaml file but the stack exists in the backend?
s

salmon-account-74572

02/21/2024, 3:21 PM
Then you'll need to run
pulumi stack select <stack-name>
and set all your configuration values for the stack before you can (or should) run a Pulumi operation against the stack. That's the point of checking the stack configuration files into source control.
t

thousands-knife-3009

02/21/2024, 3:24 PM
so, the typical/expected work flow is to configure and init everything locally then commit and move the workflow over to ci/cd?
I understand i'll need to run
stack select
to use a stack. I think I'm getting hung up on if I'm able to select a stack that only exists in the back-end and doesn't have a Pulumi.,<stack name>.yaml file
In my POC, I used Pulumi to manage Cloudflare DNS records and the only thing that exists in the Pulum.main.yaml file is the "encryptionsalt".
Apologies for any confusion, I'm still drinking my coffee and waking up. 🙂
s

salmon-account-74572

02/21/2024, 3:28 PM
so, the typical/expected work flow is to configure and init everything locally then commit and move the workflow over to ci/cd?
I'd say so, yes.
I think I'm getting hung up on if I'm able to select a stack that only exists in the back-end and doesn't have a
Pulumi.,<stack name>.yaml
file
You should be able to, yes. You just won't have any stack configuration values. If you haven't set any stack configuration values, then you should be good to go. If you do need stack configuration values...then you'll want to set those and commit the stack configuration file into source control. 🙂
t

thousands-knife-3009

02/21/2024, 3:32 PM
Can "encryptionsalt" be set at the project level? if so, can I just make it any base64 string or does pulumi expect something specific in it?
s

salmon-account-74572

02/21/2024, 3:34 PM
"encryptionsalt" == the password for the secrets provider, which is what allows you to store secrets in the stack configuration file in encrypted form (which is why it's safe to commit the stack configuration files into source control, because secrets are never exposed in plain text). I don't believe that this is configurable at the project level.
t

thousands-knife-3009

02/21/2024, 4:33 PM
@salmon-account-74572 is the encryptionsalt an encrypted representation of the PULUMI_CONFIG_PASSPHRASE or is it a salt that's appended to the passphrase when accessing config secrets?
nvm, it seems that the value for encyrptionsalt changes if you
pulumi stack select foobar --create
then delete the local Pulumi.foobar.yaml file and then run
pulumi preview
the preview command regenerated the Pulumi.foobar.yaml file with a different salt value despite the back-end config already existing.
oh, i just found that
pulumi config refresh
will recreate the stacks yaml file complete with the previously existing salt