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:
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:
- Run code to respond to an event on GitHub
- GitHub will run anything in a virtual machine
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!
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