I was an early employee at CircleCI. I have used, in anger, nearly every CI system that has ever existed. Jenkins, Travis, CircleCI, Semaphore, Drone, Concourse, Wercker (remember Wercker?), TeamCity, Bamboo, GitLab CI, CodeBuild, and probably a half dozen others I’ve mercifully forgotten. I have mass-tested these systems so that you don’t have to, and I have the scars to show for it, and I am here to tell you: GitHub Actions is not good. It’s not even fine. It has market share because it’s right there in your repo, and that’s about the nicest thing I can say about it.
Buildkite is what CI should feel like. But first, let me tell you what CI should not feel like.
If You’re a Nix Shop, You Can Leave Early
Before I get into it: if you’re a Nix shop, take a look at Garnix. It evaluates your flake, figures out what needs building, and builds it. No YAML. No pipeline configuration. It just looks at your flake.nix and does the right thing. Sometimes the best CI configuration is no CI configuration.
Most shops are not Nix shops. This post is for the rest of you. I’m sorry.
Part I: The Descent
The Log Viewer, or: Where Your Afternoon Goes to Die
Let me start with the most visceral thing, the thing that will sound like I’m exaggerating but I am not.
Your build fails. You get a red X on your pull request. You click through to see what happened. This is where the ordeal begins.
First you land on the checks summary page, which shows you a list of workflow runs. Maybe one failed. Maybe three failed. You click the one that looks relevant. Now you’re on the workflow run page, which shows you a list of jobs. You click the failed job. Now you’re on the job page, which shows you a list of steps, all collapsed. You click the step that failed. The page hitches. You scroll. There is a pause, a held breath, and then the logs appear, slowly, like a manuscript being revealed one line at a time to a supplicant who has not yet proven worthy.
... continue reading