Pantheon is pleased to offer a new GitHub Application and a GitHub Action, two different models for deploying to Pantheon.

Over the past few years, Pantheon has seen our ecosystem gravitate toward adopting GitHub Actions. The pull seems largely fueled by a desire to have fewer SaaS companies in between the code on your laptop and your live site. 

Here's how the options look today:

For teams who are not yet doing any GitHub to Pantheon integration but want to try the simplest approach, check out the Application.

For teams already using GitHub Actions to push code changes to Pantheon, we recommend trying the Pantheon-maintained GitHub Action. We expect it will make your workflow configurations simpler and more maintainable for you without changing much else. See the readme for more detailed guidance.

How we got here

Our platform was created over a decade ago with the wisdom that deployments to every Drupal and WordPress site should run through a Git repo. Before the ubiquity of GitHub, GitLab and BitBucket, that meant Pantheon needed to host its own Git repos.

With every passing year, the percentage of teams who would prefer to interact only with the Git repo on GitHub goes up. For a decade, we've accommodated that use case with various scripts and examples, most notably Build Tools. 

Build Tools became popular when we added capacity to spin up fresh instances of Pantheon sites, third-party Git repos, and the Continuous Integration (CI) services in between. The biggest value of Build Tools was (and still is) the shrinking hours of manual copy/pasting down to one command: build:project:create.

But Build Tools never fully solved a companion challenge facing many teams doing CI (or most any software development) — the entropy of aging and diverging scripts. Build Tools can make you a copy of CI scripts tailored to WordPress, but over time you will probably modify those scripts for your own project. At that point, understanding the line between boilerplate and custom code is nearly impossible.

Enter new GitHub integrations

For a few years, we thought the one solution to the entropy of CI scripts would be to make a GitHub Application to fully eliminate the need to deal with the two repos (one Pantheon-hosted and one on GitHub). That Application would then also delegate to Pantheon common CI responsibilities like "composer install" to our Integrated Composer feature. We still think there's value in pursuing the most simplified workflow (sign up for that private Beta!). However, internal testing of that Application showed we should also pursue incremental simplification for teams already deep in the CI space.

Our own usage of the GitHub Action

One of the reasons I was confident we needed to provide our own "Push to Pantheon" Action was that I would use it on my own personal site. Like so many Pantheon users, I too want to make a pull request on GitHub and have the code show up in a Multidev environment.

Image

In 2019, I wrote a "CircleCI Orb" to accommodate the same workflow. Six years later, I still have CircleCI stickers on my laptop but if I can drop extra SaaS steps between me and my websites, I'll do it. That seems to be one of the defining trends of the last few years. 

To effectively compete with a robust and mature platform like CircleCI, GitHub Actions needs to support complex and configurable workflows beyond the "just push the code" part that is satisfied by our App and Action. Here's a slightly more complex example that shows coding standards checks happening in parallel to the "push" job and Playwright tests waiting for the push to complete.

Image

What's next?

If you're interested in trying out our Action, you can do so right away. Just follow the instructions in the readme file. If you run into any trouble, let us know in the issue queue. Also, subscribe to our YouTube channel to get a notification about an upcoming livestream where we will walk through real usage of the action.

If you want to sign up for beta access for the Application, do so here.