Choosing between interactive stack selection and PULUMI_STACK for CI‑friendly workflows

Question

Goal: Ensure that stack selection is both discoverable for developers working locally and reliable in automated CI pipelines.

Constraint: Interactive prompts (e.g., `pulumi stack select`) improve discoverability but block non‑interactive environments, while setting the `PULUMI_STACK` environment variable skips prompts and enables CI but can hide misconfigurations if the variable points to a non‑existent stack. The `--non-interactive` flag provides a safety net by failing on any prompt, yet it may abort unexpectedly in exploratory sessions where occasional input is needed.

Uncertainty: How to balance discoverability, safety, and automation without requiring developers to manually unset environment variables or remember to add flags?

Should the CLI emit a warning when `PULUMI_STACK` references a stack that does not exist?
Could a hybrid mode automatically fall back to an interactive prompt only when a terminal is detected and no explicit `--non-interactive` flag is present?
Is there value in deprecating one approach in favor of a unified configuration method that preserves both discoverability and CI safety?

Wasi · Answer

To balance discoverability and CI reliability, use the PULUMI_STACK environment variable for CI and rely on pulumi stack select for local development.The most effective strategy is to decouple the environment selection from the CLI's interactive state. By using environment variables in automation, you ensure the pipeline is non-blocking, while allowing developers to use the interactive features of the CLI locally.

The Recommended Workflow

Local Development: Use pulumi stack select  once. This updates the .pulumi/stack.yaml file, ensuring subsequent commands (like pulumi up) target the correct environment without prompting.
CI/CD Pipelines: Define the PULUMI_STACK environment variable in your pipeline configuration (e.g., GitHub Actions secrets, GitLab CI variables). This overrides any local state and ensures the pipeline targets the intended environment.
  Safety Net: Always include the --non-interactive flag in CI scripts. This forces the CLI to fail immediately if it attempts to prompt for input, preventing the pipeline from hanging indefinitely.

Addressing the Concerns
While PULUMI_STACK is the standard for automation, it does introduce risks. Here is how to mitigate them:

Missing Stacks: The Pulumi CLI will return an error if PULUMI_STACK points to a stack that does not exist. You do not need a custom warning; the failure of the command itself is the appropriate signal for a misconfiguration.
  Hybrid Mode: While the CLI doesn't natively "fall back" to interactive mode based on terminal detection, you can achieve this with a simple wrapper script or a Makefile. However, simply using pulumi stack select within a terminal is usually sufficient as it persists the state for that session/directory.
  Deprecation: There is no value in deprecating either approach. They serve different contexts: one is for human-driven exploration, and the other is for machine-driven execution.

Implementation Example
In your CI configuration, the command should look like this:

# Example for a CI step
export PULUMI_STACK=prod
pulumi up --non-interactive --yes

This ensures that even if the environment is misconfigured or the stack is missing, the process exits with a non-zero code without waiting for input.

Choosing between interactive stack selection and PULUMI_STACK for CI‑friendly workflows

1 answer

To balance discoverability and CI reliability, use the `PULUMI_STACK` environment variable for CI and rely on `pulumi stack select` for local development.

The Recommended Workflow

Addressing the Concerns

Implementation Example

Your perspective belongs here.

0 question comments