This message was deleted.

If you are on 2.0.0, yes. See https://github.com/pulumi/pulumi/blob/master/CHANGELOG.md#200-2020-04-16 for more info about this.

Hmm gotcha. It seems that Pulumi’s recommendation to simply get the latest version during CI isn’t a good one then. This means that any CI workflow that is relying on the latest version and was not using

--yes

will now fail.

Can you point me to where we recommend that? We should likely update that.

https://www.pulumi.com/docs/guides/continuous-delivery/gitlab-ci/#prerequisites It’s the second bullet point

Thanks. I'll open an issue to add a note to those about pinning versions.

I think recommending to install a specific version, or at least a version range that will have no breaking changes, should be done for CI

I’m getting this issue as well.. I’m using the pulumi CircleCI orb located here: https://circleci.com/orbs/registry/orb/pulumi/pulumi#commands-update

@strong-iron-54278 I believe you can specify

version

as part of the login command to pin the version.

You can indeed set the version in the CircleCI orb :) I’ve just updated all my CircleCI builds to use Pulumi 2.0.0

Pinning the version now. @green-morning-1318 are you using the pulumi orbs?

Yup

By the way, would it be possible to have a behavior similar to 1.0 back? It was very useful for

--yes

to be implicit in CI. For example, could we set a

PULUMI_NON_INTERACTIVE

env var to not have to pass

--yes

?

Why that instead of just passing

--yes

?

Right now we have scripts that take care of deployments, we call these in CI. We also call these manually. Being able to turn this functionality on during CI while not hardcoding it in the scripts would be very useful. Hardcoding it in the scripts would make the scripts dangerous to run locally. Using

--yes

outside of the script’s context doesn’t make it clear where that argument is going. For example, we have npm scripts called

deploy

but they might not all use Pulumi. Running

npm deploy -- --yes

for all packages isn’t right since not all deploy scripts will expect that argument

Seems more like it should be in your script to do this. The change was explicitly done so that if you are in a non-interactive environment, it didn’t auto apply.

It’s not very ergonomic to have to wrap every call to

pulumi up

with this logic. Wouldn’t you agree that having some sort of environment variable would help?

Personally no since I would want it to be explicit in the command.

For example, instead of having

"deploy": "pulumi up"

, we would need to do

"deploy": "if [ \"PULUMI_NON_INTERACTIVE\" = true ]; then pulumi up --yes; else pulumi up; fi"

As noted above - the motivation for this change was to fix a real risk of accidentally auto-accepting an update. I do think this was worth addressing. In general, it does seem in general you will want different commands to execute for "non-interactive" vs. "interactive" workflows. For the former, you will want

--yes

or

--skip-preview

. For the latter you will want the interactive review workflow. Can you give more detail on why you want a single

pulumi up

command in scripts that covers both of these scenarios?

For example, I’d just do a

deploy:ci

script and then you don’t have to worry about it.

We have a monorepo managed by Lerna and Yarn workspaces. The way we make a package “deployable” is by having a

deploy

script in package.json. We were just trying to reuse the exact same scripts during CI while having any interactive requirements turned off. We could have scripts with conditional logic or have separate scripts as @cool-egg-852 just suggested and all this would be fine. It just would mean that now we have two sources of truth as far as deployment scripts go. This is not a big issue, really just a small QoL change.

What I’m suggesting is adding the global auto update as an opt in.

Curious what you'd want that to look like? An env var perhaps?

Yup, maybe something like

PULUMI_NON_INTERACTIVE=1

?

Yeah - I think that's a reasonable thing to consider adding. Want to open an issue to suggest it?

I wouldn’t call it that, because it isn’t explicit in what it does. It simply implies it is non-interactive, which is exactly where this change was made. Instead, maybe

PULUMI_ALWAYS_YES=1

Yeah, perhaps that name is more appropriate

The ALWAYS_YES part makes sense to me. The other name doesn’t. But the idea makes sense if it helps your needs.