I've been using the auto API to try to create an option when running pulumi up such that all of my stacks get brought up, rather than having to select each stack I want to bring up. The reason I wanted this behavior is because when I use Pulumi in a CD pipeline, I have to keep my stack names in my workflow, which seemed like an opportunity for human error if we forget to add a stack name that should be brought up by the workflow. Perhaps my use case for wanting to just run pulumi up on all my stacks is anti-pattern, but it would be nice to have a way to tell Pulumi to run pulumi up for all my stacks (or possibly all stacks that aren't within a denylist) within the context of a CD pipeline.
For additional context, I have ~100 stacks that I want deployed via a GitHub action, where each stack represents all the infrastructure components of a Kubernetes cluster (VMs, load balancers, databases, etc.). My ideal workflow was that an operator would create a new stack that represents a new cluster, submit a PR that has the stack definition (Pulumi.mynewcluster.yaml), and when the PR gets accepted, Pulumi would bring up the new stack. I was planning on using a GitHub action to deploy all my stacks, but that also meant I would need to ensure all my ~100 stack names (plus any new stacks created by any operators) were included in the action, which didn't seem ideal. In a way, I am trying to make Pulumi work in a GitOps inspired environment.
Instead of using the auto API to try and deploy all of my stacks, I instead just create stacks per cloud platform the cluster should be deployed to (aws, azure, gcp). Then, I just namespace the config variables for the cluster within the stack. The downsides to this approach are that now I have to namespace the outputs for each cluster, and trying to teardown a cluster with pulumi down is a bit less ergonomic, since the stack now contains all the clusters for a cloud platform, rather than representing a single cluster.
General Feedback
I've been using the
autoAPI to try to create an option when runningpulumi upsuch that all of my stacks get brought up, rather than having to select each stack I want to bring up. The reason I wanted this behavior is because when I use Pulumi in a CD pipeline, I have to keep my stack names in my workflow, which seemed like an opportunity for human error if we forget to add a stack name that should be brought up by the workflow. Perhaps my use case for wanting to just runpulumi upon all my stacks is anti-pattern, but it would be nice to have a way to tell Pulumi to runpulumi upfor all my stacks (or possibly all stacks that aren't within a denylist) within the context of a CD pipeline. For additional context, I have ~100 stacks that I want deployed via a GitHub action, where each stack represents all the infrastructure components of a Kubernetes cluster (VMs, load balancers, databases, etc.). My ideal workflow was that an operator would create a new stack that represents a new cluster, submit a PR that has the stack definition (Pulumi.mynewcluster.yaml), and when the PR gets accepted, Pulumi would bring up the new stack. I was planning on using a GitHub action to deploy all my stacks, but that also meant I would need to ensure all my ~100 stack names (plus any new stacks created by any operators) were included in the action, which didn't seem ideal. In a way, I am trying to make Pulumi work in a GitOps inspired environment.Instead of using the
autoAPI to try and deploy all of my stacks, I instead just create stacks per cloud platform the cluster should be deployed to (aws, azure, gcp). Then, I just namespace the config variables for the cluster within the stack. The downsides to this approach are that now I have to namespace the outputs for each cluster, and trying to teardown a cluster withpulumi downis a bit less ergonomic, since the stack now contains all the clusters for a cloud platform, rather than representing a single cluster.