← Back

Probot App or GitHub Action? (Updated)

This is a second post on the same topic - the first was published before GitHub Actions v2 was introduced.

Spoiler: it (still) depends.

GitHub Actions and Probot are two totally separate projects with the same end goal: to enable and empower developers to extend their workflows, and make GitHub work exactly how they want it to. I get questions about when I’d use either one, and while a lot of the original version of this post is still true, Actions has evolved since then. A quick primer on each tool:

GitHub Actions

I won’t go too deep into what Actions are - you can check out the official docs to learn more. The important notes for right now are:

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

The key point is that GitHub runs your Actions in an ephemeral virtual machine - 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. These can be either Container actions (code that runs in a Docker container) or a JavaScript action, where the JS code is run immediately inside the virtual machine.

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.

It’s been enabling developers to build automation and workflow tools for a while - I like to think of it as an inspiration for Actions!

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 6 hours. That means that (and this isn’t an exaggeration) you can run whatever code you want in a virtual machine so long as it doesn’t take longer than that time - and GitHub will run it for you 😍.

Actions are intended to be reused across workflows - you can “import” an action and use it, even if the code lives outside of your repository, sort of like a dependency. One vitally important Action is actions/checkout - it clones the repository that the workflow is running in, and allows your workflow to interact directly with the repo’s code.

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. One concrete example - let’s say you want to simply log all insta