icy-dress-8337103/24/2021, 3:31 PM
. These two projects are in different folders, with different yaml files. Each had their own stack created, but when I say
pulumi login --local
in one of the projects folders, I seem to get both stacks accross multiple projects. I noticed this only because I tried to name the stack in both projects "dev". Am I doing something wrong here, or is this a byproduct of using local login or something?
pulumi stack ls
millions-furniture-7540203/24/2021, 3:37 PM
look the same in both projects? This file contains the project name.
bored-oyster-314703/24/2021, 3:56 PM
stacks that are in the same project • OR, prefix your stack names with the project name. I.E. project
may have stacks
icy-dress-8337103/24/2021, 4:25 PM
pulumi cannot differentiate them on a project level? These are mostly just local testing at this point anyways, my plan is to use blob storage for state as I used to with terraform, so I guess with that, this problem would solve itself?
bored-oyster-314703/24/2021, 4:26 PM
so we just place all projects in their own directory in our S3 bucket and that works for us.
icy-dress-8337103/24/2021, 4:27 PM
bored-oyster-314703/24/2021, 4:28 PM
icy-dress-8337103/24/2021, 4:28 PM
bored-oyster-314703/24/2021, 4:29 PM
usage. Start specifying your backend in the
. Because as you discovered when you use
it sets that file state backend as your current backend in the
file in your user directory and then it is very easy to forget that it will preserve that login across directories and pollute your backend
icy-dress-8337103/24/2021, 4:38 PM
bored-oyster-314703/24/2021, 5:16 PM
parameter that you can set.
icy-dress-8337103/24/2021, 5:19 PM
bored-oyster-314703/24/2021, 5:44 PM
in one pulumi project directory, and then
pulumi login ...
to another project directory and forget that file state backends don't differentiate and that I need to
again. Me setting the
pulumi login ..
is my way of not causing issues when I'm developing locally. In a pipeline, this is a non-issue because you can just have it
everytime - or in automation API you can put the
and just set your ENV vars on the workspace. But locally, if those environment vars are required for the azure blob backend, than my recommendation to ditch the pulumi login usage wouldn't work for you - because you also need to remember to change the values of those ENV vars and those can't be set in the YAML files. Unless of course all of your azure blob backends use the same ENV var values, in which case just setting the
with the project name suffix in each project YAML will be fine because you don't ever need to change the ENV vars.
icy-dress-8337103/24/2021, 6:44 PM