← Back

Probot App or GitHub Action?

There is a newer version of this post that is more up-to-date with changes to GitHub Actions. Check it out!

Spoiler: it depends.

Since GitHub announced the beta release of GitHub Actions in October 2018, there’s been a new excitement around building automation - and that’s awesome! But I wanted to take a look at the various pros and cons of GitHub Actions and Probot, where each excels and where each might not be the best tool for the job.

GitHub Actions

I won’t go too deep into what Actions are - @jessfraz has got you covered. The important notes for right now are:

  1. Run code to respond to an event on GitHub
  2. GitHub will run anything in a Docker container

The key point is that GitHub runs your Actions in an ephemeral container - there’s no hosting, server costs or deployment to worry about. It’s sort of like a scoped serverless function that’s triggered by events in a GitHub repository.

Probot

Probot is an open-source framework for building GitHub Apps in Node.js. It handles boilerplate things like authentication, and provides a straightforward EventEmitter-like API.

We were working on Probot for about 2 years before GitHub Actions - I like to think that it inspired parts of Actions, but I have no idea if that’s true.

It’s been enabling developers to build automation and workflow tools that whole time. That’s something I really want to stress - Actions is amazing, but it’s not the only way to build automation; sometimes it’s not even the best way.

What’s best for you?

Let’s start by talking about GitHub Actions’ sweet spot. It’s the kind of automation tool that I’d never want to build using Probot: something long-running.

At the time of writing, Actions has a timeout of ~59 minutes. That means that (and this isn’t an exaggeration) you can run whatever code you want in a Docker container so long as it doesn’t take longer than an hour - and GitHub will run it for you 😍.

It’s got another trick up its sleeve: every Docker container comes with a clone of your repo.

So to me, the best use for Actions is something that makes use of your codebase. Things like deployment or publishing tools, formatters, CLI tools - things that need access to your code. These are also all use-cases that aren’t required to be really fast - if your NPM package takes a few minutes to publish, that’s slow but not the end of the world.

That brings me to Actions’ major weakness: they can be slow. We’ve got super smart folks working on Actions, and I know that s