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
with.
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 :-).
--
Matthew
--
Want to help the Review Board project? Donate today at
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/reviewboard?hl=en
---
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.
