Summary: We distinguish between Github statuses that are errors and waiting differently (instead of treating them all as a failed passed_status . In the case where there are no errors and some waiting statuses, notify with a response and wait polling with an exponential backoff until we're in some other state than "no errors and some waiting statuses" (i.e., patch_preflight returns something else).

I allow this RFC document to be modified and redistributed under the terms of the Apache-2.0 license, or the CC-BY-NC-SA 3.0 license, at your option.


When using the pr_status feature to filter allowed pull requests, it really makes more sense to actually wait for it to finish, rather than immediately erroring. This process can also time out, so it is also necessary to expose a configuration option for changing that timeout.

Guide-level explanation

There are two ways to gate on a GitHub Status CI report. The regular status option is used to watch for CI runs on the staging branch. The other, pr_status, is used to watch for integrations that only run on pull requests. Bors will wait for the PR status to complete before it merges into the staging branch.

Reference-level explanation

Change the documentation for pr_status. Also add documentation for this configuration option.

pr_statusList of commit statuses that must pass on the PR commit when it is r+-ed before it will go into staging. If it is still running, bors will wait. If it fails, bors will fail immediately.
prerun_timeout_secTimeout while waiting for pr_status checks to finish.


Other than code complexity, there are really no user-facing reasons to avoid doing this. It's obviously better in the cases where a PR status is still running. There are no known cases where users would prefer the old behavior, really.

Rationale and alternatives

  • Not doing this is a pretty terrible option that got a lot of complaints before someone eventually got around to implementing it.
  • As for doing this with a different setup, the obvious alternative is to add a separate config option for "insta-fail statuses" and "waited statuses". If anybody wants that, let me know!

Prior art

Unresolved questions

  • The question that came to my mind, that I'd like to know about, is the one described in the "alternatives" section: does anybody have any status changes that they don't want bors to ever wait on? That is, does anyone actually prefer the old behavior?

Future possibilities

There are a bunch of pre-checks. Right now, we only poll statuses, but maybe we'd want to poll some of the others? Even if it's only with super-short timeouts to try to work around potential race conditions.

See also

Implementation status


  • Pull request: