--stack option broken in pulumi CLI

[d-nishi]

Use Case: In order to enable automation of multiple stacks within one project or multiple projects, a user may need to non-interactively program the stack option in 1 go.

$ mkdir myeks && cd myeks && pulumi new aws-typescript --name myeks --description "my eks cluster" -c aws:region=us-west-2 works as expected however

$ mkdir myeks && cd myeks && pulumi new aws-typescript --name myeks --description "my eks cluster" -c aws:region=us-west-2 --stack d-nishi/dev throws the following error:

error: no Pulumi project found in the current working directory.

[d-nishi]

@arun-gupta -- FYI.

[justinvp]

There's a related discussion in #2614

This is fallout from changing stack identities to include the project name. The code we use to parse stack names, used throughout the CLI, will attempt to lookup the project name if it wasn't included in the stack name. It does this by looking for the project name in Pulumi.yaml, but in this case, the lookup fails because this is happening before we've laid down the project files, so Pulumi.yaml doesn't exist.

The fix is to be smarter about this in pulumi new. If we know what the project name is going to be (e.g. when --name is specified explicitly, or when --yes is used to accept the default suggested project name, etc.) we should just use that as the project in the stack name, rather than trying to look it up in a non-existent Pulumi.yaml file.

In the meantime, this can be worked around by specifying a fully qualified stack name that includes the project name, e.g.:

$ mkdir myeks && cd myeks && pulumi new aws-typescript --name myeks --description "my eks cluster" -c aws:region=us-west-2 --stack d-nishi/myeks/dev

[stack72]

@d-nishi is this also related to / duplicate of #2822 ?

[chrsmith]

I'll take a swing at this while Matt is out.

[justinvp]

@chrsmith, mind if I take this? I already have a bunch of context paged in memory.

[justinvp]

Some cases to consider:

• pulumi new typescript --name myproj --stack myorg/mystack: Project determined by --name
• pulumi new typescript --yes --stack myorg/mystack: We could have this use the default value that would be used for the project name, but I'm leaning towards just not supporting this case as the behavior of using the default value is non-obvious.
• pulumi new typescript --name foo --stack myorg/bar/mystack: Should we error since the project specified to --name doesn't match the project in the stack name?
• pulumi new typescript --stack myorg/myproj/mystack: Should we extract the project name from the stack name in this case as if it was specified to --name?

[mikhailshilkov]

I'll be able to fix this with tests when #3065 is reviewed and merged

[mikhailshilkov]

pulumi new typescript --name myproj --stack myorg/mystack

Agreed. Same for pulumi new typescript --name myproj --stack mystack

pulumi new typescript --yes --stack myorg/mystack: We could have this use the default value that would be used for the project name, but I'm leaning towards just not supporting this case as the behavior of using the default value is non-obvious.

Currently, it takes the default value of the folder name. I think this makes sense, at least I go forward with the suggested default most of the time. I suggest to keep it.

pulumi new typescript --name foo --stack myorg/bar/mystack: Should we error since the project specified to --name doesn't match the project in the stack name?
pulumi new typescript --stack myorg/myproj/mystack: Should we extract the project name from the stack name in this case as if it was specified to --name?

These are tricky:

1. Project name is a part of the stack name only for the pulumi backend. Therefore, it's a black box for the pulumi new command: currently, it doesn't know about the project in there at all.
2. The shape org/proj/stack is not allowed for the prompted stack name.

My preference would be bring stack argument on par with the prompted value and disallow the org/proj/stack shape. If we don't want to make breaking changes, we can keep the current status-quo, or maybe add a warning.

Keeping #3076 in mind, it makes sense to me to just have three independent arguments for the owner, project, and stack.