On 2013-06-10 16:02, Christian Hammond wrote:
On 2013-06-10 13:32, Allan Caffee wrote:
Is any way to have code automatically committed/pushed to Subversion/Git
once a requisite set of users have given a review a ShipIt! I believe some
other code reviews support this and I was curious if anyone has attempted
this and whether it's something the ReviewBoard community would be
interested in.

This feature is something we've talked about, but there's not a
greatway of achieving it in all cases, at least to a level we're comfortable

The problem boils down to three main things:

1) Handling authentication. Every user would need to store their
auth details or SSH keys, and there's a lot of thinking that must be
done there, plus we'd need to start coming up with different
scenarios for who can push and how.

Not so for git. I would expect that the tool has some configuration for who has permission to approve for merge, and that the merge itself is be done by an account designated for that purpose. (This is roughly how gerrit works.) So only the merge account needs credentials, and those can be easily managed by the admin that sets up the merge tool.

For svn (with no distinction between author and committer), this is a much bigger problem :-).

2) Having a checkout available. Not required in all cases, but at
least with Git, where this is often wanted, you would need a full
clone  in order to push.

True, but not insurmountable. Especially if this is done (at least initially) as a separate, external process.

3) Handling merge conflicts. We wouldn't provide conflict
resolution, so it'll often be easier just to do this outside Review
Board. (Otherwise, people would just get annoyed when merging doesn't
work all the time.)

An easy solution would be for the merge-bot to simply reject any request if it fails to merge cleanly. The author would then need to update the request so that it merges cleanly (e.g. by rebasing, merging in master, etc.). That should at least work for an initial pass.

Now, there are some things we can do with hosting service APIs, in
theory, maybe. There's been talk of a big Merge button that merges a
change in, if the API gives us the ability to do that. Still, even
there, we have to solve a number of problems.

I think this is going to be much easier to develop (initially at least) as an external process, that only needs some notification from RB that a request should be merged. Especially as I would find it much more acceptable for said tool to only work with e.g. git.

For git, the only major obstacle I see is how to know what to merge. This *requires* at least a symbolic (but preferably SHA) moniker of the branch (not the branch field which is - at least in my setups - used as the also-required merge target). I would be perfectly happy to (ab)use changenum for this purpose if there were a way to set it, and as an initial pass just reject manually uploaded requests.

Then there's a question of how paranoid the tool is as far as verifying that what it actually merges matches the request, but that's mostly gruntwork to solve. (The only perfect solution I think is to recreate the diff and compare against the request diff. The SHA is a good check against mistakes, but not actively malicious users.)

Disclaimer: I read Allan's original post as offering to write something. So take the above as encouragement that I believe that should be possible, not complaint that the core RB team hasn't already done it :-).


Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 
--- You received this message because you are subscribed to the Google Groups "reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to