travis-yml VS combine-prs-workflow

More likely they hacked their YAML parser to treat on as a string.

At least that's what Travis CI folks did:

https://github.com/travis-ci/travis-yml#user-content-yaml

To address inefficiency caused by separate PRs, a workflow was designed to join them automatically into one big PR. However, it was unable to deal with lockfile conflicts. PRs that caused conflict in the Combine PRs job, were omitted and you had to add them manually anyway. It spared some time, but the developer experience was still far from being perfect.

Another pitfall I ran into recently with a workflow I've been working on [1]: Checks and CI that are made with GitHub Actions are reported to the new Checks API, while some (all?) external services report to their old Statuses API. This makes it needlessly difficult to ascertain whether a PR/branch is "green" or not. They finally decided to create a "statusRollUp" that combines the state of the two APIs, but it's not available in their REST api, only their GraphQL API.

[1] https://github.com/hrvey/combine-prs-workflow/

GitHub Actions can do some neat things. I got tired of waiting for Dependabot (tool that makes automatic PRs to update your middleware, acquired by GitHub) to add an option to group PRs together (it opens a separate PR for each dependency that can be updated, so merging and re-running CI can take a long time) so I scratched my own itch and made a workflow that merges their PRs together: https://github.com/hrvey/combine-prs-workflow Been running it for a year now, and still pretty happy with it.