Perhaps an odd scenario, but I wanted to get people's thoughts/ideas on feasibility and approach: Let's say last week our CI/CD process ran a

pulumi up

with a dynamic yaml - meaning some of the values in the

pulumi.staging.yaml

are injected by the releases process (e.g., the accounting_image_tag is pulled from another system and injected into the yaml before the pulumi up):

config:
  application:maintenance_mode: false
  application:ephemeral: false
  application:domain: company.dev
  application:accounting_image_tag: v25.02.01-rc

Then, sometime in the future, I want our CI/CD process to do another

pulumi up

with all the same values as the last successful

pulumi up

except making the maintenance_mode value set to

true

instead of

false

. What are the suggestions for the best way to account for this? Essentially, I want to run a

pulumi up

with the same yaml context as the last

pulumi up

but with one variable value changed. Thanks for the help. ~james

Normally in YAML you can make env variables that you can then pass in. I'm not sure about Pulumi if you can do the same.

Thanks Jason, this is more of the need to do a pulumi up with the current context of the last pulumi up and less to do with the yaml. So I am thinking there might be a way to call Pulumi to get the last yaml used and then adjust and pulumi up again. The alternative, which I am trying to avoid, is to have the CI/CD process store the yaml used when it does a pulumi up (in an S3 bucket for example) and the pull it down and adjust.

Pulumi recommends versioning the stack configuration file along with your programs: https://www.pulumi.com/docs/iac/concepts/projects/#stack-settings-file In this pattern, if your CI makes changes to the stack configuration, it should check in the final stack configuration file. This also gives you full transparency and a history of any changes made.

thanks, I will look at that

I've used the AWS SSM Parameter Store to store Pulumi configuration in the past. This might also be an option for you (assuming you're on AWS since you mention S3). Your CI would pull the configuration from SSM and then use it to configure the Pulumi stack. You could also only pass stack-specific SSM parameter key(s) via the Pulumi configuration (which could remain static) and then fetch the values from SSM in your program. The downside is that you get less transparency because the input to

pulumi up

does not change.

You could try this: <https://www.pulumi.com/docs/iac/cli/commands/pulumi_config_refresh/> Though when I have dynamic configs, I'd load them in through code; like fetching a list of services to configure from Google Sheets I had as part of my project code

oh - @dry-keyboard-94795 - I think that will do it. I will test it out. If my CI/CD process (in this case, it is a Runbook in Octopus) doesn't have the pulumi.[stack_name].yaml in the working directory, I can have it run a

pulumi config refresh,

which will create the flattened pulumi.[stack_name].yaml file, which can then update the application:maintenance_mode value to true. No S3 or other persistence necessary.

What you could do I think after reading it is

pulumi config refresh -s your_yaml_file_for_the_stack.yaml

I think that would work then you just set your stacks to be your different yaml files if that makes sense.