This message was deleted.

yes check the automation api. you then need to call

stack.config_set()

and then

stack.up()

to propagate the changes to the remote

Thanks Jan!

would dry run push the config and not execute the stack diff changes?

you shouldn't need to call up to propagate config with automation api. Just setting it should suffice, because under the hood it is just using the

pulumi config set

commands

does the automation api actually shell out to the cli commands, or just call the same library code that actual cli commands use

@little-summer-88406 currently it actually shells out to the CLI, which is why it requires that Pulumi CLI is installed on the host.

ah okay, is there plans for a deeper integration (in-process) without shelling out, I read something about a cwd bug the other day that sounded symptomatic of shelling out

yes, it was implemented as abstract as possible with the intention of replacing the CLI implementation with an implementation that calls out to the engine directly. There is definitely some quirks with spawning a child-process to invoke the CLI but there is still some work to be done before the engine can be invoked directly, because all of that work is written in golang so currently the CLI is being used as the go-between

@bored-oyster-3147

you shouldn't need to call up to propagate config with automation api. Just setting it should suffice, because under the hood it is just using the pulumi config set commands

As far as I know, this is actually not true. It only interacts with the local file until you ask for

refresh

or

up

. (IRRC we've already had this discussion before :))

@great-sunset-355 not sure what context that discussion was had. Maybe you're thinking of how the workspace manipulates project settings? But I wrote the initial .NET Automation API - so I know that it invokes

config set

commands right away. See here https://github.com/pulumi/pulumi/blob/562c9da008e29066451be157c80579f6f387a22d/sdk/dotnet/Pulumi.Automation/LocalWorkspace.cs#L521 For both

SetConfig

and

SetAllConfig

we are immediately invoking CLI

hmm interesting, when I do this in python

from pulumi import automation as auto
from pathlib import Path

cwd = Path.cwd()
stack = auto.select_stack('staging', work_dir=str(cwd))
stack.set_config('var', auto.ConfigValue("value"))

It only sets the value locally in the file until I run

stack.up

Could this be a regression between languages?

possibly - let me look

I actually expected the behaviour you describe as well.

it looks like python is running the commands within those methods as well

From the code you shared it's clear that

.NET

SDK executes CLI, while python SDK may be doing something else?

I'm looking at the CLI code now and it looks like it might just be setting a value in the config map and not making any kind of IO request. So may just be a misunderstanding of CLI functionality on my part, if so, my mistake.

I'm 99% sure when I call

pulumi config set

via CLI it's set on both, local and remote

confusion

Hi!

pulumi config set

and therefore the relevant commands via any of the automation API sdks only set the configuration in your

Pulumi.[stack].yaml

file. To propagate it to state and to remote, you must run

up

or

refresh

.

word so just me being dumb. Thanks @red-match-15116! Guess that's especially important in Automation API where you might've made a temporary workspace and so your physical config file is transient, you'll want to make sure your changes propagate. Whereas traditional pulumi usage where you'll have a more permanent workspace / config file you're more sure that it will propagate eventually