Developing A New Pantheon Workflow Powered by GitHub Actions

Continuous Integration! A process that can cause table-flipping levels of frustration, catch critical errors before code makes it to any environment, and make non-developer eyes glaze over when an engineer is lamenting about mismatches in NodeJS versions. The TAG Engineering Team recently made some operational improvements to our continuous integration (CI) workflow on Pantheon, but before we dive into what we did we should establish a baseline of the role of CI in a web software development agency.

Here’s how Amazon Web Services defines Continuous Integration:

Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently).

So the TL;DR on CI is that it’s a series of scripts and build steps to make sure things don’t break before they get to prod (or even dev). For example, a CI script may alert a developer that something has gone horribly wrong. In this example screenshot, the CI build failed because I failed to include an `npm install` in our build process before running a build script.

Whoops! But without CI this build would have brought down our dev server. As TAG Engineers, our “Own It” value means that we are responsible for “our words, actions, and results.” This applies to code too! So CI is a way for us to make sure we’re accountable for our code and that we’re protecting our websites from crashing, even when we make mistakes (and we all make mistakes).

A New Pantheon Workflow Powered by GitHub Actions

Before we implemented our new Pantheon Workflow, our Pantheon sites were all over the map. Some of them were using the TravisCI platform to create Pantheon Multidev instances and deploy to the Pantheon development server, but deployments to test and prod were manually done. Other Pantheon sites didn’t even have CI, and built development assets (like CSS, JavaScript, and Drupal core/contrib modules) were tracked in the git repository. This made for tons of inconsistencies, merge conflicts, potential failure points, and manual work.

We needed a cleaner way of handling CI and we wanted to make things consistent across all of our Pantheon sites. So we developed a new workflow for Pantheon that leverages GitHub Actions. When we started planning for these workflow updates, we knew that our workflow needed to do the following:

• Create a Pantheon Multidev environment whenever we open a Pull Request.
• Deploy to the Pantheon dev server whenever we merge a PR to a specific branch.
• Deploy to the Pantheon test/live servers whenever we push a tag with a naming convention.

With these goals in mind, we put on our fingerless gloves like all hackers do and got to coding!

Pantheon Prerequisites and GitHub Secrets

For all of this to work, we set up our GitHub repository with a few different GitHub Secrets that we could pass to our GitHub Actions when we needed to deploy to Pantheon. For example, our `multidev_deploy.yml` file contains the following job:

      - name: Install Terminus
        uses: ackama/setup-terminus@main
        with:
          pantheon-machine-token: ${{ secrets.PANTHEON_MACHINE_TOKEN }}

 

We have a Pantheon Machine Token stored in a GitHub secret so that our actions can do all of the Terminus things we want it to do like deploy code, import Drupal config, and clear caches. We also store the Pantheon git repository info in secrets so we can use it as environment variables for our deploy job:

      - name: deployer
        env:
          pantheon_repo: '${{ secrets.PANTHEON_REPO }}'
          pantheon_site_name: '${{ secrets.PANTHEON_SITE_NAME }}'
          branch: '${{ github.ref }}'

 

Then our deploy job pushes our branch to Pantheon git repository, which will trigger a multidev environment creation in Pantheon. And it works! When we create a pull request we create a multidev environment, which allows a developer to independently test their work before we merge into the main trunk of the codebase.

We also set up some rules so that if we tag the codebase with a certain naming convention and push, we’ll deploy code to the test or live environment. Our `test_push.yml` file contains the following specification:

on:
  push:
    tags:
      - test.**

 

This means if we push a tag with `test.` preprended we’ll get a deployment to the test server. So pushing `test.v1.0` will deploy our 1.0 tag to test. It works perfectly! The same convention is used for live, so everything can be consistent between the environments.

Putting it all together (and adding asset builds)

For the first three months of our redesign project with this new Pantheon workflow, we were storing our built CSS and JavaScript assets in the git repo. One of the issues we mentioned before was the issue of built assets in the repo causing merge conflicts. This was still a problem when we first started! But thankfully we found this article by Pete Inge from Bluecadet (which builds upon another inspirational GitHub Actions + Pantheon article by Tyler Fahey) – it describes how we can use the `terminus build:gitignore:cut` command to use a different `.gitignore` file for the Pantheon repo vs. our own GitHub repo. This allows us to ignore assets until build time, when they get deployed to Pantheon. No more assets in the repo, no more conflicts for those assets!

Key Takeaways

We’re standardizing on this workflow for all of our Pantheon sites and are also working on similar workflows for other platforms we work with. There are three key takeaways from this effort that we want to highlight:

1. Continuous integration is essential for any modern software engineering project. It will help catch (most) errors before they make it to any environment and keep engineers accountable for their code.
2. GitHub Actions is a powerful and extensible tool that can support many different CI workflows. If your workflow needs are slightly different, it is very likely that GitHub actions will be able to support it! The tool is less important here: what’s important is the process and how it can increase operational efficiency + team morale. 
3. Just because a process is something that you’ve “always done” or something that “nobody has the time for” doesn’t mean that it’s worth taking a step back and looking at what you’re actually doing. You may find that investing in CI will end up in a net savings of resources and developer headaches in the long run!

---

Get in touch to learn more about how Third and Grove can help you with your Pantheon Workflows and make your CI humming with maximum efficiency.