GitHub Actions Hits GA: Free CI for Side Projects

GitHub announced general availability of Actions at its Universe conference on November 13. Actions launched in beta at Universe 2018, and back in August GitHub added CI/CD to it. Now it’s out of beta, and for a lot of side projects it means you can drop the separate CI service and its extra integration entirely.

A minimal workflow

Workflows are YAML files that live in .github/workflows/ in your repo. This one runs a Node project’s tests on every push and pull request:

name: CI
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - run: npm ci
      - run: npm test

Each job picks a runner with runs-on. The uses lines pull in published actions, here the official ones for checking out your code and installing Node, and run lines are plain shell commands. If you want to test more versions or operating systems, a strategy.matrix block turns one job definition into several, and each job can run for up to 6 hours.

What’s free

The GitHub changelog post for GA says it plainly: Actions are free for all public repositories, and every plan gets included storage and runner minutes for private repositories.

The billing docs at launch spelled out the private repo numbers. GitHub Free accounts get 2,000 minutes a month and 500 MB of storage, Pro gets 3,000 minutes and 1 GB, Team gets 10,000 minutes and 2 GB, and Enterprise Cloud gets 50,000 minutes and 50 GB. Minutes reset monthly and storage doesn’t. The catch is the multiplier. Windows jobs burn minutes at twice the Linux rate and macOS jobs at ten times, so 200 minutes of macOS builds eat the same 2,000 minute allowance as 2,000 minutes on Linux.

Going over is opt in. Your account starts with a $0 spending limit, which just stops usage when you hit the cap. If you raise it, extra Linux minutes are $0.008 each, Windows $0.016 and macOS $0.08. Self-hosted runners are free, so if you already have a spare box you can run jobs on your own hardware without touching the allowance. There are concurrency limits too: 20 concurrent jobs on a Free account, with at most 5 of them on macOS.

For a typical side project on Linux, my read is that a public repo costs nothing and a private one is very unlikely to reach 2,000 minutes unless the test suite is slow.

Keeping secrets out of logs

Sooner or later a workflow needs a token, for deploying or publishing a package. Don’t put it in the YAML. Add it under your repository’s Settings, then Secrets, and GitHub encrypts it and exposes it only to Actions. You pass it to a step explicitly, as an input or an environment variable:

      - name: Deploy
        if: github.ref == 'refs/heads/master'
        run: ./scripts/deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

The encrypted secrets docs have a few details worth knowing. GitHub automatically redacts secret values that show up in logs, but they say you still shouldn’t print them on purpose. Redaction also works best on simple values, so the docs advise against storing JSON or encoded blobs as a secret. I’d treat redaction as a safety net rather than a plan, and keep things like set -x and debug env dumps out of any step that touches a secret.

Two more things matter for public repos. Apart from GITHUB_TOKEN, secrets aren’t passed to workflows triggered from a forked repository, so a pull request from a stranger can’t read your deploy token. It also means steps that need secrets won’t work in fork PR builds, which is one more reason to guard deploys with an if like the one above. And anyone with write access to the repository can create, read and use its secrets, so be deliberate about who gets write access, and give each token only the permissions that one job needs.

Worth switching?

If your side project already has a CI setup that works, there’s no rush. But for a new repo, having builds, tests and deploys defined next to the code with no extra account and no bill for public work is hard to argue with. I’d start with the small workflow above and add a deploy step once the tests are green.