search

patronus-io / patronus

Keep dementors away from your production branches.
http://patronus-staging.herokuapp.com/
13 stars 1 forks source link

Rollup support #24

Open indirect opened 9 years ago

indirect commented 9 years ago

https://internals.rust-lang.org/t/batched-merge-rollup-feature-has-landed-on-bors/1019

bors now accepts rollup or batch commands (which do the same thing) in pull request comments.

If a PR is marked as rollup, its priority is implicitly set to -1, which means that the testing of the PR will be postponed until all other "normal" PRs are tested. When one of the rollup PRs hits the top of the queue (which means no other normal PRs are there), bors will merge all of the rollup PRs together and test them as a whole basis. This will reduce unnecessary CPU time to test one-liner doc fixes and minor changes that are not likely to break things (which is why we've had manual rollups).

However, you can also manually trigger the rollup even when there are one or more normal PRs. Just set p=[Very high number, such as 76527] to one of the rollup PRs. bors will place it at the top of the queue and make a rollup immediately.

Note that the rollup command is independent to other commands, just like p=. You can add or remove the rollup tag at any time.

The rollup feature has been only added to the rust branch21 of bors. As the master branch got diverged a bit, we cannot apply these changes to master directly. It would be great to see both branches got unified someday.

segiddins commented 9 years ago

This would require storing state....

indirect commented 9 years ago

We already store some state, and if this is going to get big on a single installation, we'll probably have to store more state eventually :P

On Fri, Aug 14, 2015 at 1:53 PM, Samuel E. Giddins notifications@github.com wrote:

This would require storing state....

Reply to this email directly or view it on GitHub: https://github.com/patronus-io/patronus/issues/24#issuecomment-131236593

segiddins commented 9 years ago

We don't store any PR or build-level state, which is something I love about the current design. Not opposed to adding this functionality, but it'd require some pretty big foundational work.