Skip to content
DevOpsGitHubContinuous IntegrationDockerOpen Source

I ❤️ GitHub Actions

Example workflow for a GitHub Action

Since being accepted into the beta for GitHub Actions a few months ago, I’ve found a new side hobby of whipping up new (and ideally creative) actions for anybody to add to their CI pipeline. Actions are modular steps that interact with a GitHub repository and can be coded with Docker or JavaScript/Node — and either way, they can be as simple or as complex as you want. But in both cases, they’re incredibly fun to make and the results always scratch my itch for instant gratification.

My favorite so far is my Lighthouse Audit action, which spins up a headless Google Chrome instance in an Ubuntu container and runs Google’s Lighthouse tool, which scores webpages on performance, accessibility, SEO, etc. and provides actual suggestions to improve them. It’s a perfect example of the power of combining containers with Git workflows.

The results of a Lighthouse audit on this website, after running tests in a headless Google Chrome.

The results of a Lighthouse audit on this website, after running tests in a headless Google Chrome.

It’s also been a fantastic avenue to dip my feet into the collaborative nature of GitHub and the open-source community. I’ve made some small apps in the past but these are the first projects where I’m regularly receiving new issues to help out with and impressive pull requests to merge. It’s a great feeling!

Here are the actions I’ve made so far, sorted by popularity as of this posting:

As an example of an extremely simple (and almost completely unnecessary) action, the Wait action takes one input — a unit of time — and has the pipeline sleep for that amount of time. The Dockerfile is as simple as this:

...with a super-short

Using an action is also surprisingly simple, and more intuitive than Travis CI or CircleCI, in my humble opinion. Pipelines in GitHub Actions are called “workflows,” and live in a file with YAML syntax in .github/workflows. An example of a workflow.yml file that uses the above action to wait 10 seconds (on both pushes and pull requests) would look something like:

For a more complex example, when I forked Hugo (the static site generator used to build this website) to make some small personalized changes, I also translated their .travis.yml file into a workflow.yml file for practice, which simultaneously runs comprehensive unit tests on three operating systems (Ubuntu 18.04, Windows 10, and macOS 10.14) with the latest two Go versions each! If the tests are all successful, it builds a Docker image and pushes it to both Docker Hub and the GitHub Package Registry (also in beta).

Build logs for my Hugo fork

Then another workflow, which lives in this website’s repository, pulls that Docker image, builds the Hugo site, and pushes it to GitHub Pages. All astoundingly fast. All for free.

A plethora of actions is already published on the GitHub Marketplace, with dozens more being added every week. If you are not yet in the beta, I urge you to sign up here and give it a shot. GitHub has been very receptive to feedback (so far) and I can’t wait to see GitHub Actions evolve into an enterprise-grade CI tool at the level of other competitors in this space. ❤️