This message was deleted.

You're right... looks like it should be without the v2

Sorry it way just my go ignorance that was the reason. In the go module it helped with

module "chipper-environment-initializer"

go 1.16

require (
   <http://github.com/pulumi/pulumi/sdk/v2|github.com/pulumi/pulumi/sdk/v2> v2.10.1
)

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.

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?

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?

yeps

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

$(Build.SourceDirectory)/path/to/project/one/

etc

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