Re: Automatically commiting code upon receiving a ShipIt!
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.
Re: Automatically commiting code upon receiving a ShipIt!
On Jun 10, 2013, at 12:01 PM, Matthew Woehlke 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. > > AFAIK there is not such a tool at present. I for one would definitely be > interested in having one available. > > That said, I don't think it is going to be possible right now for git (unless > you are doing only pre-commit review without a 'branchy' workflow, which is > probably less common) as there is not a standard way of recording the branch > head that you could use to perform a merge. (This is *VERY* high on my wish > list.) > > What might be manageable in the current framework would be if there is some > way to stuff the SHA that matches the request into the changenum field. >From > this it is possible to derive the symbolic name of the branch (i.e. for > pretty merge commit messages). At any rate, you want the SHA no matter what > as it ensures that what you are merging actually matches the request. > > For svn, it is easier because you aren't dealing with an existing commit. In > either case you are probably talking about separate tools/extensions at least > for git and svn, possibly even two different ones for git (for pre- and > post-commit review). > This feature is something we've talked about, but there's not a great way 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. 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. 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.) 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. Basically, it's just not something we'll be getting to any time soon. We don't really want to be your front-end to your SCM or your patch merge tool. We want to be your review tool. That's where our focus is right now, and we're working on things to improve that. Maybe down the road, we'll figure out a good solution to pushing code. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org Beanbag, Inc. - http://www.beanbaginc.com -- 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.
Re: Automatically commiting code upon receiving a ShipIt!
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. AFAIK there is not such a tool at present. I for one would definitely be interested in having one available. That said, I don't think it is going to be possible right now for git (unless you are doing only pre-commit review without a 'branchy' workflow, which is probably less common) as there is not a standard way of recording the branch head that you could use to perform a merge. (This is *VERY* high on my wish list.) What might be manageable in the current framework would be if there is some way to stuff the SHA that matches the request into the changenum field. From this it is possible to derive the symbolic name of the branch (i.e. for pretty merge commit messages). At any rate, you want the SHA no matter what as it ensures that what you are merging actually matches the request. For svn, it is easier because you aren't dealing with an existing commit. In either case you are probably talking about separate tools/extensions at least for git and svn, possibly even two different ones for git (for pre- and post-commit review). -- 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.
