Is it possible to use the Node.js automation API to deploy multiple projects with different names without destroying resources from other projects? When I deploy multiple projects (i.e. multiple

stack.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.

Hi Brian! Indeed the PR you linked is intended for exactly this functionality. I have concurrency working via the automation API in that PR, but have yet to resolve the regressions introduced to some other tests. It should be very close to done, but I haven't had time to come back to it and finish it off.

Hey Kyle! Thanks for the prompt response, no worries at all. Honestly I didn't realize Node.js had something similar to the golang/Deno context module until going down this path and looking through your PR haha. Thank you for the closure and clarification 😄

Happy I could be helpful! These context implementations for both Node and Python are relatively new! There was an earlier PR to implement this for Python, but Node has a few extra gotchas that have slowed it down a bit. I'm hopeful to have this done soon, though!

ah, actually it seems like my problem is different, and very strange. I just tested with the Pulumi CLI and got the same results (the two stacks in the screenshot are separate Pulumi stacks/micro-stacks with separate directories). So I think my problem was completely detached from the automation API and is instead closer to an issue with my state: Interestingly, if I rename the stacks to something other than "one" and "two", the problem completely goes away. This leads me to believe I have some corrupt state, however I tried completely removing the stacks and recreating them (

stack 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!