Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Add PR "rollups" #34

Open
brson opened this issue Jun 11, 2014 · 6 comments · May be fixed by #46
Open

Add PR "rollups" #34

brson opened this issue Jun 11, 2014 · 6 comments · May be fixed by #46

Comments

@brson
Copy link
Collaborator

brson commented Jun 11, 2014

Rust frequently has a dozen small PR's in the queue and we are near our throughput limit for serially landing them, so we frequently "rollup" multiple branches into one PR. bors should have a simple way to do this automatically, maybe r+ rollup.

cc @alexcrichton
@brson brson mentioned this issue Jun 11, 2014
Closed
@Gankra
Copy link

Gankra commented Dec 4, 2014

Notes from discussion today:

Would like a rollup and try directive.

try would have bors test out the PR on the try branch. This is useful for quick-checking human-made rollups, which often fail, without blocking the queue.

rollup would mark the PR as a candidate for an automatic rollup. This would add an implicit p=-1 to the PR, meaning it will only be merged normally if all other PRs are also p=-1. Automatic rollups should occur once per day.

Example usage:

Someone makes a manual rollup. You accept it with the following directive:

r+ try p=10

This will have bors run the branch under try first, and only on success place it in the queue as accepted, with p=10.

Someone makes a documentation change that is expected to trivially pass and not conflict with anything else. It would be a waste of resources to run the full test suite on just this patch in isolation. You accept it with the following directive.

r+ rollup

This marks the PR as p=-1, and it will be merged at the end of the day with all other rollup PRs into a single job with p=1.

CC @cmr @brson

@frewsxcv
Copy link
Contributor

Someone makes a documentation change that is expected to trivially pass

If for whatever reason a merge conflict does happen, should it avoid the rollup altogether? Possibly try different combinations of commits?

@Gankra
Copy link

Gankra commented Dec 10, 2014

This is a good question. In my head I picture something like: merge commits in order, if one causes a conflict, drop it and continue. Best effort rollup.

@Gankra
Copy link

Gankra commented Dec 10, 2014

As a first draft you could have it abort, though.

@larsbergstrom
Copy link

From Servo's point of view, we are planning toadd @bors: try so that you could do so without implying r+.

One important bit is that try processing should always happen after any r+ or retry processing (due to the laggy polling-based nature of bors, at least in Servo's branch of it).

@barosl barosl linked a pull request Dec 12, 2014 that will close this issue
Open
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
271146f 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
a1d4f5e 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
050a695 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
48a8692 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
2ee3138 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
1805f50 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
5807cf4 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
f57c6cc 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
afc1e2b 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
barosl added a commit to barosl/bors that referenced this issue Dec 12, 2014
@barosl
Add batched merge (rollup) feature
e9c468f 
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
@chris-morgan chris-morgan mentioned this issue Dec 14, 2014
Open
@dwijnand
Copy link

dwijnand commented May 3, 2018

Fixed by #47?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add batched merge (rollup) feature barosl/bors
5 participants
@brson @dwijnand @frewsxcv @larsbergstrom @Gankra