rich-dress-42878
10/05/2022, 6:37 PMstack.up({ ... })
calls with different values for projectName
), even when forking the process or similarly calling the script multiple times with different stacks enabled, resources from all stacks except for the "current" stack end up being deleted. It seems to me like this is because of global stack state mentioned here, and possibly the Node.js parallel execution limitation mentioned here. The only way I have found to fix this is by providing a homogeneous projectName
parameter for every LocalWorkspace.selectStack
call.
I thought this might be unintended behavior due to the Go multi-stack orchestration example having two project names: inlineMultiStackWebsite
and inlineMultiStackObject
, however I might be doing something wrong/misunderstanding.
Is this PR a potential solution, or is that an unrelated issue? I am aware that LocalWorkspace
and the Node.js automation reference spec explicitly mention LocalWorkspace
support for a "single project", which I assume is why only one unique stack (by name) can exist in my testing. I also saw @little-cartoon-10569's message here which mentioned the ability to use multiple projects. However, I am not sure how to get this to work.creamy-agency-52831
10/05/2022, 7:10 PMrich-dress-42878
10/05/2022, 7:12 PMcreamy-agency-52831
10/05/2022, 7:13 PMrich-dress-42878
10/06/2022, 6:13 AMstack rm
) without luck. Maybe the projects "one" and "two" have the same reference in the state. Worth noting I'm locally hosting state since I'm just testing Pulumi right now. Unfortunately this is hard for me to reproduce, I suppose I could just move on starting completely from scratch (removing all Pulumi state) or just use different stack names.
In any event my problem is "fixed" but there is still some confusion as to the state issue (or other issue), and also I wish I could provide some repro steps
Or of course I'm still missing something and there was just a bug in my code/workflow!