I reading information on the checks version of Travis, and I noticed something: Travis Pull Request builds are built against the merge of the PR onto upstream.
Firstly: cool, we did it! Travis changing the default to build a merge onto upstream instead of the pushed commit is a big win for small projects.
Of course, it doesn’t help much when multiple PRs are in flight at the same time, as it only does this once when the PR build is triggered. Any pushes to upstream after the PR was last updated could break the merge build, thus bors still has its use (and of course, when sectioning off a smaller test suite for auto-PR-builds).
It would, however, be nice to be able to reuse this work. Maybe it’s not solvable in the general case of multiple CIs worth of checks, but for Travis, a Travis CI - Branch check on the staging branch should be equivalent to a Travis CI - Pull Request check on a PR that is against master and is updated more recently than master.
This would be a generalization of reusing pull request work where the PR is a fast-forward to master, for the specific case of only Travis as the status check.