I just can't stand using a build system tied to the code host. And that is really because I have an aversion to vendor lock-in.

webhooks to an external system was such a better way to do it, and somehow we got away from that, because they don't want us to leave.

webhooks are to podcasts as github actions are to the things that spotify calls podcasts.

To be honest, GitHub actions made a big impact at a time when every other CI framework sucked, really badly. Maybe today, others are much better than they used to be!

I agree with the gripes, but buildkite is not the answer

If I cannot fully self host an open source project, it is not a contender for my next ci system

I don't have much experience with Guthub Actions, but I'll say this does sound worse than Azure DevOps, which I did not imagine was possible. I've never liked any CI system, but ADO must be one of the lower circles of hell.

I matured as an Engineer using various CI tools and discovering hands-on that these tools are so unreliable (pipes often failing inconsistently). I am surprised to find that there are better systems, and I'd like to learn more.

GitHub Actions isn’t killing engineering teams; complacency in CI design is. CI should be reliable, inspectable, and reproducible, not just convenient.

I was excited for actions because it was “next to” my source code.

I (tend to) complain about actions because I use them.

Open to someone telling me there is a perfect solution out there. But today my actions fixes were not actions related. Just maintenance.

I don't care if this is an advertisement for buildkite masquerading as a blog post or if this is just an honest rant. Either way, I gotta say it speaks a lot of truth.

We started using Buildkite at $DAYJOB years ago and haven't looked back. Incredibly, GitHub Actions seems to have gotten _worse_ in the interim. Absolutely no regrets from switching.

Is it great? No. Is it usually good enough? Yes. CI shouldn’t be a main quest for most engineers. Just get it rolling early and adjust as needed.