Improve pull request fetching by filtering out draft PRs

[diraol]

Hey folks, how are you doing?

I am using bors in a private repo with a huge number of contributors and contributions (avg of 400 PRs merged per week, reaching almost 1k open PRs at some point). And in a context with a huge number of tests/checks per PR (~100 different tests taking up to 2h to run everything).

Due to this scenario, we have been facing some difficulties with bors and our guess is that is due to the size of the project (PRs + checks). For example bors taking 1h+ to recognize that all checks for the current running batch had already finished with success.

So we are looking at ways to improve the situation, and we have two paths to pursue.

One is improve the code to gain performance (more parallelism? Reshape some logic on fetching github?). On this sense, maybe deploying bors in a cluster with more bors nodes would help, I guess - but I still need to learn how to do it since I'm not from erlang/elixir world.

One other way is to reduce the load over bors. We are already putting in place some tools to close stale PRs, but we still have 600+ ongoing PRs on a daily basis and hundreds of checks. So what we were thinking is that eventually if we change most of the "still under development" PRs to "Draft" status and setup bors to not fetch Draft PRs we would see some real impact.

My question is: Does bors have some kind of config to "filter out" Draft PRs? (like not even fetch those PRs from github). If not, would it be possible to do so?

Thanks!

[notriddle]

One is improve the code to gain performance (more parallelism? Reshape some logic on fetching github?). On this sense, maybe deploying bors in a cluster with more bors nodes would help, I guess - but I still need to learn how to do it since I'm not from erlang/elixir world.

That would basically require a rewrite, since bors-ng runs a single process for a single repository model. It can be parallelized, if you've got lots of repositories, but not if you have a single big one.

My question is: Does bors have some kind of config to "filter out" Draft PRs? (like not even fetch those PRs from github). If not, would it be possible to do so?

Bors doesn't have an option for this, but it shouldn't be too hard to add. You'd want to modify the webhook controller to ignore incoming messages from draft PRs, and modify the syncer to run a search query against GitHub's API to ignore drafts.

So we are looking at ways to improve the situation, and we have two paths to pursue.

Could you use GitHub's new built-in merge queues? I'm curious why you're taking the ops overhead of running bors-ng.

[diraol]

Hi @notriddle first of all, thanks for the very quick response!!!

That would basically require a rewrite, since bors-ng runs a single process for a single repository model. It can be parallelized, if you've got lots of repositories, but not if you have a single big one.

Oh... ok then. Not even going to spend a minute on this :)

Bors doesn't have an option for this, but it shouldn't be too hard to add. You'd want to modify the webhook controller to ignore incoming messages from draft PRs, and modify the syncer to run a search query against GitHub's API to ignore drafts.

I'll see if we can add that contribution to our roadmap :)

Could you use GitHub's new built-in merge queues? I'm curious why you're taking the ops overhead of running bors-ng.

We are considering it and will do tests with it.

But even if we decide to do this movement, it will take some time to be able to do it without a big impact in our contribution flow, and we need some improvements on our current setup. =/