Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Rollup support #24

Open
indirect opened this issue Aug 14, 2015 · 3 comments
Open

Rollup support #24

indirect opened this issue Aug 14, 2015 · 3 comments

Comments

@indirect
Copy link
Contributor

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
Copy link
Member

This would require storing state....

@indirect
Copy link
Contributor Author

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:
#24 (comment)

@segiddins
Copy link
Member

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

3 participants