← Back

How to start using GitHub Actions for CI

Edit: In August 2019, GitHub introduced GitHub Actions v2, with a ton of features focus on CI. The below post is outdated, but still interesting so I’m keeping it around! If you want to learn more about Actions v2, check out New features of GitHub Actions v2.


GitHub Actions can do a whole lot of things - delete branches, compose tweets via pull requests; it’s kind of a general “thing do-er.” Still, the first reaction people have is that it replaces CI. Actions are a great platform to have CI built into your workflow with minimal setup but a lot of control, so its a totally reasonable idea, but I get to use everyone’s favorite answer: it depends!

In this post, I’ll share a workflow that I’ve been using for my Node.js projects, as well as some extensions to it for additional functionality. We’ll also take a look at features of popular CI tools and see how they map to GitHub Actions.

Some pre-reading

I’ll be delving into the nitty-gritty of writing a workflow file, including some lesser-known functionality. I’d encourage you to read my previous blog post on GitHub Actions workflows, where I talk a bit about workflows as a whole.

You may also want to familiarize yourself with the actions/bin repo, a collection of actions that are highly scoped and useful for composing a workflow without writing any custom code (especially actions/bin/filter).

But I love {{ ci_provider }} - why should I care?

I’m not saying that existing projects should migrate their CI to Actions. Rather, new projects benefit from the minimal setup of a CI workflow if you know what you’re doing. Are GitHub Actions the best CI platform? I’d say it really depends on your needs; if you’re just running tests and viewing the logs/status, you can get a lot of functionality with very little effort (I know, the dream 😍).

A typical Node.js workflow

This is a main.workflow file that I’ve been using for a couple of projects and it’s been a great experience. With most CI providers, I need to follow these steps:

  1. Push a configuration file to my repo
  2. Go to their site and find my repo
  3. Hit a checkbox/toggle to enable that CI provider to build my repo
  4. Push again to trigger CI

Nowadays, I create my .github/main.workflow file and this is my whole process:

  1. Push a configuration file to my repo

75% efficiency improvement! Because most of m