https://pulumi.com logo
#pulumi-deployments
Title
# pulumi-deployments
l

lemon-agent-27707

06/14/2023, 4:21 PM
Announcing Review Stacks - powered by Pulumi Deployments 🚀 https://pulumi-community.slack.com/archives/CB36DSVSA/p1686759675815729
q

quiet-gold-81036

06/16/2023, 7:56 AM
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.
l

lemon-agent-27707

06/16/2023, 2:56 PM
@quiet-gold-81036 Have you checked out our startup offer? https://www.pulumi.com/pulumi-for-startups/
our mono-repo setup does cause some over-provisioning
Deployments supports path filters so that certain stacks only get targeted by certain directories in your mono repo. We use it in one of our infrastructure monorepos. There are also some interesting patterns you can put to use with review stacks, such as using mutliple programs to share certain resources across review stacks. https://www.pulumi.com/docs/pulumi-cloud/deployments/review-stacks/#customizing-behavior-with-multiple-pulumi-programs https://www.pulumi.com/docs/pulumi-cloud/deployments/review-stacks/#customizing-behavior-with-path-filters
q

quiet-gold-81036

06/16/2023, 8:53 PM
Thanks for the links, looks promising
d

dry-journalist-60579

06/22/2023, 7:19 PM
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:
Copy 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
Copy code
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",
)
l

lemon-agent-27707

06/23/2023, 3:58 PM
@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:
Copy code
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.
If you have ideas on how we could improve the documentation, would love your feedback: https://www.pulumi.com/docs/pulumi-cloud/deployments/review-stacks/#separate-stacks We do plan to add a "getting started" for deployments soon, and that will include some concrete examples of configuring review stacks among other things.
d

dry-journalist-60579

06/23/2023, 4:25 PM
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.
18 Views