This is a quick guide to set up GitHub Actions for Pulumi with an AWS S3 backend. It builds on a previous guide I wrote: How to Use an AWS S3 Bucket as a Pulumi State Backend.

This guide assumes you have the following:

• An AWS S3 Bucket created and ready to be used with Pulumi
• An IAM User that has permissions to read/write to the S3 bucket
• The Access Key and Secret Access Key for the IAM User to use for authenticating to AWS within GitHub Actions
• A passphrase of your choosing that will be used to encrypt secrets in the pulumi stack
• A GitHub repository

Setting up Repository Secrets

First, set up secrets on your GitHub repository. These will be filled in by GitHub Actions once we create a workflow YAML. You’ll need to create 3 secrets. You can name them whatever you want, but I’ll be naming them:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• PULUMI_CONFIG_PASSPHRASE

You can create these by browsing to your GitHub repository > Settings > Secrets and variables > Actions. There are “Environment secrets” and “Repository secrets”. In this case go with “Repository secrets”.

Create the three secrets and fill in their respective values. PULUMI_CONFIG_PASSPHRASE can be whatever you want and doesn’t come from AWS.

Warning:

Make sure you don’t change this passphrase after the fact, or your Pulumi state may break.

The end result should look like this:

Defining the GitHub Actions Workflow

Next, clone the repository locally with git clone. We’ll need to create a few files for a minimum viable Pulumi program. Run pulumi new and it’ll guide you through the creation of a basic Pulumi program. The language you choose doesn’t matter.

Then we can create the YAML file to set up GitHub Actions. Create a YAML file under <your-repository-name>/.github/workflows/. I’ll call it preview.yml in my example. Fill it in with the following YAML, changing values as needed.

name: Pulumi
on:
  push:
    branches:
      - main # change this if you're using a different branch name

jobs:
  preview:
    name: Preview
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Pulumi Preview
        uses: pulumi/actions@v6.6.1
        with:
          command: preview
          stack-name: dev # change this to your stack's name (or whatever you want it to be if it doesn't exist)
          cloud-url: s3://nelson-test-bucket-for-github-actions # change this to your bucket name to be used as a pulumi backend
          upsert: true # creates a stack if it doesn't exist (along with Pulumi.<stack>.yaml)
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          PULUMI_CONFIG_PASSPHRASE: ${{ secrets.PULUMI_CONFIG_PASSPHRASE }}
          AWS_REGION: us-east-1 # change the region as needed

This runs a pulumi preview so it’ll verify that everything is set up correctly without actually deploying anything.

Testing the Workflow

Now push your code to GitHub and see if the GitHub Action workflow ran successfully. You should see output from a successful pulumi preview.

If this works, you should be good to go. You can update your Pulumi code and change command: preview to command: up in the GitHub Actions YAML file and run it again to actually deploy some infrastructure.

References

• https://github.com/pulumi/actions

For example, the beginning of my GitHub Actions YAML file looked like this:

name: Deploy
on:
  push:
    branches:
      - master

This configuration allows for workflows to run on commit pushes to the master branch, but there is no option to run this workflow manually on GitHub:

To enable manual runs of workflows, I added the workflow_dispatch key. There was no need to add anything else under it:

name: Deploy
on:
  push:
    branches:
      - master
  workflow_dispatch:

After pushing changes, I was able to see a “Run workflow” button that allows me to run the workflow manually.

You can also run workflows using the GitHub CLI once workflow_dispatch is in your workflow YAML file. Assuming your workflow YAML is named main.yml, you can run:

gh workflow run main.yml

And you’ll get output similar to the following:

✓ Created workflow_dispatch event for main.yml at master
https://github.com/nelsonfigueroa/nelson.cloud/actions/runs/22656361802

To see the created workflow run, try: gh run view 22656361802

Note that there are a lot more configuration options available when adding the workflow_dispatch key. However, I just wanted to enable manual runs and nothing more. Refer to the documentation for more information.

References

• https://docs.github.com/en/actions/how-tos/manage-workflow-runs/manually-run-a-workflow
• https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch
• https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
• https://cli.github.com/manual/gh_workflow_run

Note:

Git Emails

When setting up Git on the command line, you are asked for your email. When pushing commits to GitHub, the email you are using for Git gets pushed along with your code as part of the metadata. While your GitHub email does not publicly show when viewing a repository’s commits, it does come up when viewing commits using the GitHub API.

This presents a privacy risk and the potential for someone to find the email associated with your GitHub account. I wanted to see how easily someone could do this so I created a scraper to do this for me. It turns out it’s not hard to scrape commits for emails that are otherwise hidden from public view.

Disclaimer:

I don’t plan on doing anything malicious with this script or the emails collected. I did this out of curiosity and for demonstrational purposes.

The scraper I created is below. Instructions can be found on the README:

• https://github.com/nelsonfigueroa/github-email-scraper

Scraping for Emails

By running the script, I can scrape for emails found in each commit for a given repository:

$ ruby main.rb -u torvalds -r linux

	+-------------------+
	|   GitHub          |
	|       Email       |
	|         Scraper   |
	+-------------------+


Scraping https://github.com/torvalds/linux/
Rate limit exceeded.
Pages scraped: 1-46 out of 10449
53 emails written to torvalds-linux.txt

Just like that, I’ve scraped several emails. It’s not much, and I could get a lot more if I bothered to authenticate to prevent rate limiting. A patient scraper could simply run this periodically to get as many emails as possible.

So what can we do about this?

Hiding your Email in GitHub Commits

You can choose to hide your email when performing Git operations on the GitHub site as well as the command line. There are two checkboxes you’ll need to tick. Instructions are below:

• Blocking command line pushes that expose your personal email address

Next, you’ll need to change your email Git uses on your machine to the @users.noreply.github.com email that GitHub provided in the previous step. Run the following:

$ git config --global user.email "00000000+yourusername@users.noreply.github.com"

Then verify that the email has been set:

$ git config --global user.email
00000000+yourusername@users.noreply.github.com

Now your actual email will be hidden from Git commits that have been pushed from your machine as well as any Git operations on GitHub. Note that your email will still show up in older commits that were pushed before these changes. However, this will still improve your privacy on GitHub going forward.