| forgive me if my information is outdated, but: - 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.