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.

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?

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 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?

what if i don't have a Pulumi.<stack>.yaml file but the stack exists in the backend?

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.

so, the typical/expected work flow is to configure and init everything locally then commit and move the workflow over to ci/cd?

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. 🙂

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?

"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.

@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?