Hi I am trying out the go example for multi stack ...
# automation-api
Hi I am trying out the go example for multi stack here -> https://github.com/pulumi/automation-api-examples but as far I can see the used packages are not located on github on the places they should, where can i find theese?
Copy code
package main

import (


func main() {
   ctx := context.Background()
   stackName := "salesforce"
You're right... looks like it should be without the v2
Would you mind raising an issue for that please? https://github.com/pulumi/pulumi/issues
Sorry it way just my go ignorance that was the reason. In the go module it helped with
Copy code
module "chipper-environment-initializer"

go 1.16

require (
   <http://github.com/pulumi/pulumi/sdk/v2|github.com/pulumi/pulumi/sdk/v2> v2.10.1
If you know about the automation api can you then perhaps tell me how to select dotnet as runtime using the go automation code? seems like there are options or is this not possible?
So your automation api code is go but the pulumi program is dotnet?
Yes, Maybe we are doing it wrong but in our pulumi organization we have 15 projects with different stacks, we would like to create a new stack with a specific name on all of these pulumi projects. And then we will trigger our Azure DevOps to build, test, pulumi stack update and deploy. We think we can use pulumi automation for this but maybe we are wrong. We tried out the dotnet example but it seems like its depending on local workspace and we would like to leave that out.
by leave out we would like to use something like the NewStackRemoteSource thats available in Go https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v2/go/x/auto#example-NewStackRemoteSource
but it also requires a workspace 😞
I think maybe there is some confusion about what a workspace is - it's just a local directory. The dotnet automation api, if a working directory is not provided, will just select a temp directory to use. Automation API requires a "workspace directory" because under the hood it is still using the CLI. Does that make sense?
👍 1
So if you want to use the Automation API to execute an existing pulumi program, you would set the working directory to the directory that contains that pulumi project. Automation API refers to this as a "local program"
Thank you for the clarification!! Is the NewStackRemoteSource also available in the dotnet automation code? Cant seem to find the code/documentation
that is the "remote program" support and you can see https://github.com/pulumi/pulumi/issues/6459 here that it was decided that that will not come to dotnet. Granted all that does is
git clone
your pulumi project into the workspace directory before running as a local program so it wouldn't be too difficult for you to do that yourself inside the pipeline
thanx! First step is to init the stack for each project in our organization, one of them requires config. Is this possible without github access and file access to the pulumi code? We would like to machine/devops independent so we would like not to specify where each project is located on the dev machine running this automation program
You would like to create new stacks for existing pulumi projects without using the existing pulumi project code?
but if the code is required we can off course add that
with github checkout etc
I use Azure DevOps at work. You don't need to make it machine dependent to reference your pulumi code. Your ADO pipeline is probably doing
git checkout
by default, you just need to set the working directory relative to the root of your source. There should be pipeline variables to make that simple. Like
You don't even really need automation API for this specific use-case tbh, you could use pulumi CLI in your pipeline. You just either need your build agent to have the CLI installed or to use a container job where the CLI is installed in the container
okay, we did that first, but thought it was a lot of extra work since we could use the automation api instead
ah. Well the Automation API has the same requirement, it needs the CLI to be installed - so once you have that on your build agent or a container for containers jobs setup you can go whichever route you think is simplest