https://pulumi.com logo
Title
b

better-shampoo-48884

03/21/2021, 2:13 PM
I noticed that the automation-api leverages the typical Pulumi.yaml and Pulumi.<stackname>.yaml files - any chance of these being declared as part of the code instead? Would much prefer to have these synced in a database or something to go stateless..
c

clever-byte-21551

03/21/2021, 2:25 PM
AFAIK you can define everything by code, this is how i’m using it:
project := workspace.Project{
		Name:    tokens.PackageName(projectName),
		Runtime: workspace.NewProjectRuntimeInfo("go", nil),
	}
	w, err := auto.NewLocalWorkspace(
		ctx,
		auto.Program(deployFunc),
		auto.Project(project),
	)
	if err != nil {
		return nil, errorlib.Wrapf(err, "failed to create workspace")
	}

	w.SetEnvVar("PULUMI_CONFIG_PASSPHRASE", passphrase)
b

better-shampoo-48884

03/21/2021, 2:27 PM
nice! have you tried it with remote state / secrets?
it is a bit tricky to navigate the docs at the moment, so didn't see the workspace bit til now
c

clever-byte-21551

03/21/2021, 3:09 PM
I’m using S3 backend for the state and a passphrase secret store (others didn’t work so well with the automation API at the time)
b

bored-oyster-3147

03/21/2021, 4:17 PM
The first version of the automation API still depends on the CLI under the hood so it likely will rely on those project/stack YAML files until the CLI is no longer a dependency Their should be APIs for you to manipulate those files on the workspace, but you will hit a wall if your files contain complex objects instead of just string/string KVPs. In that case you’ll need to handle the serialization yourself.
You can use remote state by either using the environment variables that specifies the backend, or by setting it in the project settings YAML file
b

better-shampoo-48884

03/21/2021, 4:21 PM
thanks 🙂