Hi all, I am playing around with the cli and had a question in regards to the

pulumi config

functionality of the CLI. I am looking to perform a step in my CI/CD where I save application app settings into the pulumi stack.

pulumi config set --path "AppSettings.$name" $value $securityOption;

However I found that the config does not persist in later steps when a

pulumi config refresh

is performed prior to me performing a

pulumi up

. Is this expected behavior? Do I need to run a

pulumi up

right after the config step in order for the config to persist? Thank you!

Yes, that's how it works in most (all?) remote environments provided by services like GitHub, GitLab, etc. To solve this via git, you can put that config into a committed stack file. To solve this via your CI service, you can identify those files as artifacts; I believe for all of those services, that files marked at artifacts are made available to later stages in pipelines. I know it works that way for Jenkins, GitHub and Bitbucket.

Yeah I'd prefer to just commit the config directly to the stack file but am getting some developer friction when it comes to touching infra code. Was hoping that I could pull their files and inject them into the stack as a step as a solution. I guess the TLDR of the question is - if I do

pulumi config set

is this supposed to be saved in the backend instance or just my local?

pulumi config

updates the stack config file, which is local (normally shared via git). If you want shared config, you need to use something like a vault, AWS SSM, or Pulumi ESC.

so what does a

pulumi config refresh

do?

That's something I learned about only in the last day or so. I don't know. It may be that there's more to this than originally observed...

Thank you - that might be the way to go 👀 Regarding if a project is ready to deploy, do you reckon there's a way I could target the config specifically with

pulumi up --target

? (to avoid a full deployment)

Not sure. I see

--exclude

takes wildcards.. that might be abusable?

Will give it a go, thank you for the guidance

You could abuse --exclude to skip most things but provider resources can't be excluded, so the

up

run will update their state.