https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
r
pulumi stack ls
should show a 
*
next to the current stack
👍 1
b
That works. Where is that saved? Seems to be 
~/.pulumi/workspaces
, not entirely sure I understand how workspaces work tho. Thanks 🙂
👍🏽 1
r
now you’re asking the hard questions 😆 I imagine somewhere in 
~/.pulumi
😄 1
Aha looks like you got it. I think of workspaces as the representation of the pulumi project on your machine
b
FYI most (if not all) stack related commands in the CLI accept a 
--stack
or 
-s
argument to specify the stack you want to operate on, if you want to forgo messing with what stack is currently selected
b
I would have liked to have the equivalent of 
terraform workspace show
but 
pulumi stack ls
will work for now (albeit a bit slow). I do use the 
--stack
command sometimes, especially since all my stacks are in the same project (because of https://github.com/pulumi/pulumi/issues/2814)
b
That issue doesn't force all your stacks to be in the same project, it just means that project name is not part of stack identity with S3 backend. You could have separate projects if you wanted, you would currently just need to namespace your stack names by project name
b
I guess I confused the word project, they are in different projects (i.e. different folders with a Pulumi.yaml each), but 
pulumi stack ls
still returns all the stacks of all the projects that share the backend. So I could technically have
Copy code
.
├── a
│   └── Pulumi.yaml
└── b
    └── Pulumi.yaml
and go into 
b
and do 
pulumi stack select a.dev
b
ah yea, I guess in that sense they are all in the same project in that all stacks are always accessible. my bad
b
No worries! I was kinda hoping the current selected stack was easily accessible (say an environment variable) so that way I could at least have a different TTY in each folder, each with a different stack selected. Right now I either have to use 
-s
on every command, or change selected stack in each folder (but that's very error prone)
b
when you're developing locally it's definitely a pain. But I think when you're setting up your pipelines and automation just specifying 
-s
on everything is a good solution
6 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by