A Quick Intro to GitHub Actions

Background

GitHub introduced the beta version of Actions recently, aiming for a GA on November 13th at the time of this writing.

Actions provides a containerized environment for building CI/CD workflows and adding general automation around a project, similar to offerings from GitLab and CircleCI. The free tier is very generous, offering unlimited build minutes for open-source projects and 50,000 free minutes per month for enterprise customers. Actions are composable and reusable, and there are loads of useful public ones available. One example is an Action that auto-deletes merged branches (Note that GitHub recently released a native feature for this).

Anatomy of an Action

A GitHub action is made up of jobs and steps. Jobs can be run in parallel or sequence, and can be configured to depend on the success of other jobs. A job has one or more steps. A step can be a predefined action, or a command to run.

Configuration

Actions are configured in the project itself in .github/workflows/*.yml files. As the asterisk implies, more than one Action can be created in a repo. The syntax for Actions is documented here.

Actions can be scheduled, or can be triggered by basically any event you can think of on GitHub. A push, a PR, a commit comment, etc can all be triggers. These triggers can be as granular as you want. For example, this event would trigger only when a PR is closed:

on: 
  pull_request:
    types: [closed]

Usage for testing

Running tests against every pull request shortens the feedback loop and is a check against having a broken build make it into a deployment pipeline. GitHub Actions allow for persisting test artifacts in zip format, which is well-suited for uploading test results. The retention is 30 days for pull requests. To upload artifacts, invoke actions/upload-artifact in a build step.

Usage for deployment pipelines

Actions isn’t ready for prime time here yet. There are a few issues with its current iteration that make it unsuitable for a production environment. One is that secrets are currently defined at the repository level, not the organization level. So if you ever need to change these, it requires redefining them in every project. Another issue is that there is no functionality for manually approving deployments. There also isn’t any sort of view to visualize a pipeline. Contrast this to the functionality that CircleCI provides:

Given that CircleCI, GitLab, and BitBucket all have pipeline views and functionality, GitHub will likely add these in a future release.

Resources

I created a cheatsheet of useful syntax and snippets here.