Allow Pulumi config vars to be dynamically set

[ziahamza]

• This PR allows pulumi vars to be automatically set from environment variables passed by Github Action
• Setting a secret in GH such as "PULUMI_CONFIG_XYZ=20" would set pulumi config XYZ to be 20

[chrsmith]

Is there a specific scenario that this PR enables? On the surface this approach seems like it is a step in the wrong direction. (Though perhaps I'm just unaware of when you'd want to do this.)

Configuration changes are stored in the Pulumi.<stack-name>.yaml file, and stored in the source repository. This is a very intentional decision. Because that way the Stack configuration is tied to the specific commit, and so scenarios like rolling back to a previous version is less scary because the configuration is deterministic. (i.e. using the config in Pulumi.yaml at that particular commit.)

By introducing any sort of dynamism here, you can standup a stack where the configuration isn't tied to the source code. And could lead to difficulties when trying to revert changes or rollback to a previous version. (Not that we would want to explicitly prevent that, it's just something we'd want to avoid enabling without a compelling reason.)

As far as the code is concerned, this only allows you to specify a single configuration value, and not pass --secret if needed. So if we did want to support this scenario, it seems like we might need an approach that is more flexible anyways.

[ziahamza]

I 100% agree for staging / prod environments to live as a checked in file.

But this PR gives rise to support of dynamic review links. Basically, when its a user branch, goal is to create a brand new branch specific pulumi environment to test the PR in isolation. With end goal being: https://devcenter.heroku.com/articles/github-integration-review-apps

[chrsmith]

With end goal being: https://devcenter.heroku.com/articles/github-integration-review-apps

Gotcha. Yes, that's definitely something that's come up before, and is something we'd like to support!

Though I'm still not sure just having the ability to set dynamic config is sufficient. Since you'd need to first run pulumi stack init to create the new stack, for the new pull request, right? With the right GitHub Actions configuration, perhaps running a dedicated script when the PR was created (pulumi stack init) and PR is closed/deleted (pulumi stack destroy), we could probably have the right lifecycle.

Could you write up a short document for how you would expect a Pulumi-based integration app to work? That would make it easier to understand the specific changes we'd need to make, and think through the various scenarios. (As well asallow other folk like me to pitch in.)

For example, when do you think you'd need to run pulumi config for a review app case? In that scenario would you want to "extend" the configuration of another stack? And the ability to set dynamic configuration would just be applied to that "review app stack", before every preview/update?

I hope this doesn't come across as unhelpful. I do definitely want to work with you to add this feature. But we should understand how we expect the full flow to work first, before adding individual features. (Since if we find out later that they aren't sufficient, or unnecessary, it will be harder to remove them without breaking people later.)

[seivan]

I second this ticket here since it was closed.
But my two cents would be that stacks is inherently a flawed abstraction.

I am not sure of the terminology here, but whatever pulumi creates, lets call it Set of Resources should be driving the stack and not the other way around as it currently is.

Creating these resources, should either use an existing stack or create a new one.
This would let you use build_id or pull_request as a prefix for everything named and use it to spin up everything.

Don't me wrong, stacks are useful to have pre-defined environments. But that shouldn't be a requirement.

Also, I don't think pulumi stack destroy isn't necessarily a blocker, as I would prefer it if the CI didn't destroy things. I myself don't actually use terraform destroy at all and just do manual cleanup after a merge using tags - I prefer it that way.

[EronWright]

A scenario in support of this is a github action with a step that builds a docker image (with the GITHUB_SHA as the tag), sets a Pulumi config setting (image), then pulumi up. Still deterministic but made easier with a dynamic configuration value.

[chrsmith]

Thank you for the pull request, but I'm going to close this out for now. The entry point script has moved over here, and moreover this approach is a little dangerous to use.

As far as supporting this overall feature -- setting config vars dynamically to enable review apps and things -- it is something we will get to. But like I mentioned, it is tricky to do right. (And can easily lead to outages and things if you rely on it for production stacks.)

I can report I have successfully configured CI/CD systems to use Pulumi in a review app like fashion using CircleCI and GitLab. So hopefully we'll have an example of how to do this as safely as possible using GitHub Actions soon.

Usually the trick revolves around using pulumi config refresh, to dynamically pull down a stack's configuration data and not requiring it to be checked into the repo.

Anyways, if you watch updates to this repo, you will be notified as we make changes to our Pulumi x GitHub Actions support as it evolves. Hopefully we will get to a point where we have an existing action/template that automatically does the work for managing Pulumi stacks along with the lifecycle of a pull request, etc.