No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

In what way is it not supported? `--config` option should work.

there’s no `config` option for the orb, unless I’m missing something? <https://circleci.com/orbs/registry/orb/pulumi/pulumi#commands-update>

Ah, I don't know about orbs, just know it works for the CLI itself

You should be able to do `Pulumi config` outside the orb, check in the `Pulumi.stackname.yaml` and then just do the update inside the orb. Is there a reason that does not work for your usecase?

no not really, I was just wondering if there was a way to do something like that with an orb command

No, there isn’t a way to run `pulumi config` from within our CircleCI orbs. (Feel free to file an an issue in <http://github.com/pulumi/circleci>, however.)

However, I would strongly urge you to not run `pulumi config` as part of your CI setup. The reason being is that in order to have reproduceable deployments, you need to have the same “inputs” into your stack deployment. This is why configuration information is stored with your source via `Pulumi.stackname.yaml`, instead of managed entirely on the Pulumi Service.

However, you can always just run `pulumi config` directly witin your CircleCI configuration, since we add `pulumi` to the `$PATH`.
<https://github.com/pulumi/circleci/blob/master/orbs/pulumi.yml#L45>

Thanks for that, I’m trying to piece this together at the minute. I get the principle of making sure all config is in Pulumi’s YAML, and checked into git, but I’m not 100% clear what best practice for that is in a CI/CD workflow. Keep Pulumi’s resources in a separate repo from the application, and have the app’s CI/CD pipeline check out/update/push Pulumi’s config before or after `pulumi up`?

&gt; I’m not 100% clear what best practice for that is in a CI/CD workflow.

Running `pulumi preview` or `pulumi up` in your CI/CD system is fine. (It’s how we continuously deploy our own systems.)

The main “requirement” of sorts is that you make any configuration changes (e.g. invocations of `pulumi config set`) as part of a code commit. e.g. if you want to update a deployment setting, you do that on your local machine (which would edit `Pulumi.yaml`) and then check that file in. That way on your CI/CD, you just run `pulumi up` (and not perform any configuration or source changes beyond what’s checked in). Make sense?