This message was deleted.

hi @lemon-agent-27707 this looks like an amazing feature. we've rolled out our own solution for PR-based stacks, which thanks to Pulumi's CLI is not that hard as part of our CI process, although it definitely has some sharp edges. we wanted to have our PR stacks on the Pulumi Cloud backend but unfortunately the pricing for these would be $1000-$2000 even for our small 5 man team, as we often have a number of PRs open per dev and our mono-repo setup does cause some over-provisioning. That's why we're using the S3 backend for PRs and Pulumi Cloud for prod ($400/m, very reasonable for a Series A startup) I'm assuming the Review Stacks are billed like any other stack and I was wondering if the team had any thoughts on different pricing for those stacks.

@quiet-gold-81036 Have you checked out our startup offer? https://www.pulumi.com/pulumi-for-startups/

Thanks for the links, looks promising

I’m a little confused/having trouble groking how review stacks work. We currently have the following setup: • An

infrastructure

mono repo with all our Pulumi projects+stacks. Our application code lives in separate repos (our backends and frontends). • A Pulumi project per logical grouping of infrastructure—in most cases this maps pretty cleanly to one project per application, though we have a few extra utility projects for managing other shared infrastructure. • For each Pulumi project we have two categories of stack “setups” ◦ For application-related projects, we generally have a stack for each application “environment” (e.g. development, staging, production). Even though these are “production” and “non-production” application environments, they are all “production” infrastructure. ◦ For other, more utility-related projects, we tend to have a single “production” stack. Confusingly, we don’t have a standard name for this. Sometimes it’s Pulumi.prod.yml, sometimes it’s related to the nature of the project, like Pulumi.ci.yaml or Pulumi.marketing.yaml. Side note: I’d love to come up with a word that isn’t “production” for infra to disambiguate this. Infra environments don’t necessarily correspond to application environments. • We have a single project that manages all of our Pulumi Deployment resources. We have an entry per project, per stack, but currently the

source_context

branch for all of our entries is

refs/heads/main

. • We have adopted a pattern of using a “sandbox” stack to develop new infra and make changes to infra. I think this is our version of review stacks. However, developers stand up and tear down this stack manually during the development process: 1) create a branch, 2) run

pulumi up

in the current project targeting the

pulumi-sandbox

stack. 3) make changes, run preview/up manually via CLI against the

pulumi-sandbox

stack, iterate, repeat. 4) get code review, approval 5) merge the PR and Pulumi deployments will automatically run

pulumi up

for the “production” infrastructure 6) manually run

pulumi down

to clean up resources. I guess my question is I’m imagining review stacks eliminates the need for us to manually run up/down with our

pulumi-sandbox

stacks. How would I configure this? This is our code:

def deployment_settings(project: str, stack: str, repo_dir: str):
    return pulumiservice.DeploymentSettings(
        resource_name=f"Deployment Settings: {project}/{stack}",
        executor_context=pulumiservice.DeploymentSettingsExecutorContextArgs(
            executor_image="<http://ghcr.io/OUR-ORG/pulumi-deployments-executor:latest|ghcr.io/OUR-ORG/pulumi-deployments-executor:latest>",
        ),
        github=pulumiservice.DeploymentSettingsGithubArgs(
            deploy_commits=True,
            preview_pull_requests=True,
            repository="OUR-ORG/infrastructure",
        ),
        operation_context=pulumiservice.DeploymentSettingsOperationContextArgs(
            oidc=pulumiservice.OperationContextOIDCArgs(
                aws=pulumiservice.AWSOIDCConfigurationArgs(
                    duration="45m0s",
                    role_arn="arn:aws:iam::XXXXXX:role/PulumiOIDC",
                    session_name="pulumi",
                ),
            ),
            options=pulumiservice.OperationContextOptionsArgs(
                skip_install_dependencies=True,
            ),
            pre_run_commands=["prerun.sh"],
        ),
        organization="OUR-ORG",
        project=project,
        stack=stack,
        source_context=pulumiservice.DeploymentSettingsSourceContextArgs(
            git=pulumiservice.DeploymentSettingsGitSourceArgs(
                branch="refs/heads/main",
                repo_dir=repo_dir,
            ),
        ),
    )

Usage in our

deployments/__main__.py

deployment_settings(
    project="app",
    stack="dev", # Pulumi.dev.yaml
    repo_dir="app",
)

deployment_settings(
    project="app",
    stack="prod", # Pulumi.prod.yaml
    repo_dir="app",
)

deployment_settings(
    project="app",
    stack="staging", # Pulumi.staging.yaml
    repo_dir="app",
)

@dry-journalist-60579 I'd be happy to jump on a call to discuss the details of your scenario more specifically, but I will try to add a few notes here.

I guess my question is I’m imagining review stacks eliminates the need for us to manually run up/down with our

pulumi-sandbox

stacks.

You'll need to create a new stack that acts as a template for

pulumi-sandbox

, and configure deployment settings on it: 1. Create a new stack called

pr

and copy the config from one of your sandbox stacks over to the

pr

stack. 2. Create deployment settings for that stack, this should match how you typically configure a

pulumi-sandbox

stack 3. set the branch for this stack to

refs/heads/main

-- the branch for a review stack must be the branch that pull requests get opened against 4. Set the following values in your deployment settings under the

github

key:

deployCommits: false,
		previewPullRequests: false,
		pullRequestTemplate: true,

This will configure this stack to act as a template stack. When you push commits to

main

- these deployment settings will get ignored because

deployCommits

is false, but when you open a PR these settings will be used since

pullRequestTemplate

is true. Your

pr

stack will never be updated itself, but when a pull request is opened, pulumi deployments will create a new stack, copy the config from

pr

into the new stack, copy the deployment settings over, and then run the update for you.

Ahh that’s really helpful, thank you @lemon-agent-27707!! I will try to get it it set up and then if I get it all running I’ll reflect on what may have helped me understand the docs better. Honestly, I think it’s:

This will configure this stack to act as a template stack. When you push commits to

main

- these deployment settings will get ignored because

deployCommits

is false, but when you open a PR these settings will be used since

pullRequestTemplate

is true.