- 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.
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.