Pulumi GitHub Actions

Pulumi’s GitHub Actions help you deploy apps and infrastructure to your cloud of choice, using nothing but code in your favorite language and GitHub. This includes previewing, validating, and collaborating on proposed deployments in the context of Pull Requests, and triggering deployments or promotions between different environments by merging or directly committing changes.

Let’s see how to get started – it’s easy!

Pre-Requisites

Before proceeding, you’ll need to Sign Up for Pulumi (if you haven’t already). This guide also assumes you’ve reviewed the GitHub Actions documentation and are generally familiar with its concepts and syntax.

For your workflow to do anything interesting, you’ll want to create a new Pulumi project for it. There are three ways to do this:

1. Clone an existing Pulumi example
2. Use the New Project wizard
3. Download the CLI and run pulumi new to select a template

Creating a Workflow

Although the full power of the Pulumi CLI is available to use with GitHub Actions, we recommend starting with our standard workflow, which consists of two workflow files, each triggered by common GitHub events:

1. Pulumi Preview runs pulumi preview in response to a Pull Request, showing a preview of the changes to the target branch when the PR gets merged.
2. Pulumi Up runs pulumi up on the target branch, in response to a commit on that branch.

Committing the Workflow Files

Let’s get started by adding these two new workflow files to the GitHub repository containing your Pulumi project.

The pull_request Workflow File

Add a new file to your Pulumi project repository at .github/workflows/pull_request.yml containing the following workflow definition, which instructs GitHub Actions to run pulumi preview in response to all pull_request events:

name: Pulumi
on:
  - pull_request
jobs:
  preview:
    name: Preview
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 1
      - uses: pulumi/actions@v1
        with:
          command: preview
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
          IS_PR_WORKFLOW: true

Note that we’ve set several environment variables, some of which are referenced as GitHub Actions secrets (which we’ll provide values for later), to expose to the workflow job at runtime.

The push Workflow File

Next, add a second workflow file at .github/workflows/push.yml containing the following definition, which tells GitHub to run pulumi up in response to a commit on the master branch:

name: Pulumi
on:
  push:
    branches:
      - master
jobs:
  up:
    name: Update
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 1
      - uses: pulumi/actions@v1
        with:
          command: up
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}

Now that you’ve got these two common workflows defined, you’ll need to configure your secrets. Secrets are exposed as environment variables to the GitHub Actions runtime environment. Minimally, you’ll need to supply a Pulumi access token to allow the Pulumi CLI to communicate with the Pulumi Service on your behalf, and you’ll probably want to provide credentials for communicating with your cloud provider as well.

Configuring Your Secrets

With your workflow files committed and pushed to GitHub, head on over to your repo’s Settings tab, where you’ll find the new Secrets area:

First, create a new Pulumi Access Token, then submit that token as a new secret named named PULUMI_ACCESS_TOKEN. This enables your GitHub Action to communicate with the Pulumi service on your behalf.

Next, add secrets for your cloud credentials, just as you did PULUMI_ACCESS_TOKEN above, based on your provider of choice. For example:

• AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for AWS
• ARM_CLIENT_ID, ARM_CLIENT_SECRET, and ARM_TENANT_ID for Azure
• GOOGLE_CREDENTIALS for GCP
• KUBECONFIG for Kubernetes

Try It Out!

To try things out, simply create a Pull Request or commit, and you will see these new actions showing up in the usual GitHub Checks dialog, with a green checkmark if everything went as planned:

Click the Logs pane to see the full output of the Pulumi CLI, along with the URL of your deployment on the Pulumi Console with more details:

For even better Pull Request integration, make sure to also install our GitHub App!

Pull Request Flow

If you are using Pulumi’s GitHub Actions to preview infrastructure changes from Pull Requests, you may want to have Pulumi comment on those PRs so that you don’t need to look at the specific update logs to see if there were any changes.

There are two ways to do this: using the Pulumi GitHub App (recommended), or configuring the GitHub Actions container directly.

Pulumi GitHub App

The Pulumi GitHub App is something you install on your GitHub organization. It allows the Pulumi service to leave comments on Pull Requests but does not give it access to your source code.

Once the Pulumi GitHub App is installed, when your GitHub Actions run Pulumi, a summary of any resource changes will be left on the Pull Request, as well as links to the Pulumi Console for more detailed information.

You can install the Pulumi GitHub App now, by visiting github.com/apps/pulumi or clicking the button below.

INSTALL

Example comment when using the Pulumi GitHub App:

Comments By GitHub Actions

If you don’t want to use the Pulumi GitHub App, you can configure Pulumi’s GitHub Actions to copy the output of the pulumi invocation on the Pull Request. This option doesn’t have as rich an output display as the Pulumi GitHub App, as it simply copies the raw output of the Pulumi CLI.

To allow your GitHub Action to leave Pull Request comments, you’ll need to set the COMMENT_ON_PR environment variable, and add GITHUB_TOKEN to the list of secrets passed to the action. (The GITHUB_TOKEN value will already be set in the running environment, so there’s no need to add one explicitly as a secret.) Add the following two lines to the env block of the preview action:

name: Pulumi
on:
  - pull_request
jobs:
  preview:
    ...
    steps:
      ...
      - uses: pulumi/actions@v0.0.2
        with:
          command: preview
        env:
          ...
          IS_PR_WORKFLOW: pr
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          COMMENT_ON_PR: 1

Example comment when using GitHub Actions directly:

Configuration

You can configure how Pulumi’s GitHub Actions work to have more control about which stacks get updated, and when.

Using a Different Root Directory

By default, the Pulumi GitHub Action assumes your Pulumi project is in your repo’s root directory. If you are using a different root directory for your project, simply set the PULUMI_ROOT variable in your workflow action, with a relative path to your Pulumi project directory. For example:

name: Pulumi
on:
  - pull_request
jobs:
  preview:
    ...
    steps:
      ...
        env:
          ...
          PULUMI_ROOT: infra

This tells Pulumi that the project can be found underneath the repo’s infra directory.

Branch Mappings

Pulumi has a concept of stacks, which are isolated environments for your application (e.g., production, staging, or even distinct services). By default, the GitHub Action will assume a project has a single stack, and will associate the master branch with it. For more sophisticated scenarios, this can be overridden by adding a .pulumi/ci.json file to your repository as well.

This file is simply a JSON map of GitHub branch names to Pulumi stacks. For example:

{
    "master": "production",
    "staging": "staging"
}

Often, we’ll map master to a production stack, and staging to a distinct staging stack, and then use Pull Requests to promote code between the two. This mappings file is intentionally flexible.

Note that you’ll need to create these stacks in the usual way using the Pulumi Console or CLI. After setting this up, everything will be on autopilot.

Demos and Examples

To see some examples of this in action, see the following links:

• Our introductory blog post
• Dockerized Ruby on Rails, in Kubernetes, with hosted Cloud SQL
• Short 90 second video from GitHub Universe Keynote
• Short 90 second video on GitOps and Pull Request workflows
• Longer 7 minute video exploring the ins and outs of Pulumi GitHub Actions in practice