I am not pleased with Microsoft. Yes, there have been some improvements. But GitHub Actions is very half baked, yet the bean counters at my company are asking "why do we pay for buildkite?". It feels like they are using the same playbook as MS Teams.
- You can't retry a failed action, be it manually in the UI or automatically under certain conditions.
- workflows have a pretty low limit for number of jobs - 250 or so. We already split our rspec tests across 300 parallel jobs.
- the UX is full of jank. If I click into an in-progress jobs I often can't see prior logs for the in-progress step until the step completes.
There are also some annoyances that aren't really half-baked, but annoying for Monorepos:
- workflows have to be defined under the .github folder. This means workflows can't be collocated with the code they relate to.
- workflows can't be generated dynamically. At best, you can dynamically trigger predefined workflows, but I don't think they get associated with the PR that triggered them. This makes patterns like dynamically dispatching workflows based on, say, a bazel query for affected rdeps more challenging, if not entirely infeasible.
You can retry failed jobs these days (for awhile now, at least a year? I can't remember).
Workflows can also be (sort of, depending on what you mean?) dynamically generated by using tojson and fromjson to feed the output of one job into a matrix.
Full disclosure, I work at Microsoft but nothing to do with GitHub.
One area is its reusability story. Last I looked you couldn't create reusable actions in the same repo you want to call them from, they have to be in an external repo. For quite a while, private reusable actions were an Enterprise-only feature, but that may have been lifted now. The ability to reuse particular jobs is also missing, and communication among jobs is limited to variables after the fact. You can only use success or failure states to trigger other jobs, you can't pass values.
> Last I looked you couldn't create reusable actions in the same repo you want to call them from, they have to be in an external repo.
I'm not sure if/when this changed, but you can definitely do this now.
> You can only use success or failure states to trigger other jobs, you can't pass values.
This is also not true: you can pipe environment variables to $GITHUB_OUTPUT which can be referenced by future jobs.
If anything, the main issue with GitHub Actions is that it's confusing, and the docs don't make it easy to understand how to do things at a high level.
Interesting, I'm _extremely_ happy with Github Actions. But I have pretty basic needs, admittedly.
You mention buildkite as something you think is a lot better than GH Actions. I'm curious if you've also used the Gitlab equivalent and can compare (I haven't, really).
I would not not say buildkite is better, per se. I'd say it's more mature and much more flexible. Buildkite is easily "programmable" in a way that GHA is not. That flexibility is important for advanced/large scale use cases.
