88: integration with buildbot like systems
- Fixed
- Review Board
| dsve*****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
it would be nice to send out the patch to your crowd of crazy computers beating the patch to death. one of these systems is buildbot and it comes with a 'try' feature that lets you distribute a patch to the build slaves, and there are probably other systems that provides this functionality. http://buildbot.sourceforge.net/manual-0.7.5.html#try so simply some gui for this that fires away the selected patch. but i don't know, maybe this is out of context.
-
- Type-Defect + Type-Enhancement
While complex, this would be a pretty cool feature to have. I'm not sure if Review Board is the best place to put it, but I haven't thought it through too much. It would be nice to have some sort of buildbot/sandbox integration that has a simple status field on the review request header saying "This builds." or "This fails."
+1 (Googles Issue Tracker lacks support for votes..) This was _the_ feature I was/we were looking for in patch management/review systems. In order to accept and apply a patch you want the following to hold: 1) The patch follows any coding guidelines decided upon 2) The design and workings of the patch are satisfying 3) The patch should not break existing code When doing manual code review you want to focus on functionality and design - 2) above. Minimizing everything else (in the code review) is in my opinion a big win. 1) and 3) above can (in many cases) be automated: 1) -> Lint,Hammurapi,Checkstyle,... 3) -> BuildBot,CruiseControl,... Since Review Board is supposed to cover the whole review process (as opposed to these other tools), it would be very beneficial to be able to at least see the status of the outcome of tools like that. Imagine UI labels as: "This patch follows coding guidelines" "This patch breaks rule 12.5 of coding guidelines. See report _here_." "This patch builds and has passed all tests on all platforms" Then you would have providers to create these labels, since each tool is different (just as the SCM tools). The provider would need to know where to fetch the result from any job (i.e. build or lint-run), and how to display it. To actually run the job would be the complex thing here (and out of the scope for review board). I didn't look at the database scheme for review board, but I reckon it could involve adding some states to a review or attributes to a patch - like "BUILD_PENDING" or "CHECK_SUCCESSFUL". Well, now I'm just imagening. Better stop there and call it my 2 cents..
-
+ Component-Integration
-
+ Milestone-Extensions + ExtensionIdea
-
+ Confirmed
Hudson (and presumably other continuous integration systems) makes it very easy to have builds trigger pokes of other systems. Thus there is an integration with JIRA that puts a comment on all bugs in the change list of a build. Hudson also handles patch builds well. Apache projects use this extensively by arranging for hudson to scan for issues that are in the "patch available" status. Hudson then downloads the patch, checks out the code, applies the patch and puts a comment back on the original JIRA issue. This structure could easily be adapted if there is a simple way for an outside system to scan for new reviews and a simple API for posting comments. The build system could then sift through the reviews eliminating those it has already seen or which refer to code not under a build watch. Any new qualifying builds would then be built and a summary posted.
I just did some work on this (see http://reviews.reviewboard.org/r/1336/ for a completely non-functional attempt). It is probably a very, very bad idea for this to happen automatically anywhere there is a publically availably ReviewBoard. The problem is that the patch can include arbitrary changes to the source, including buildsystem, and that can result in arbitrary actions on the slaves (as the slave user). Basically, you need to manually inspect the patch, then try it.
Just for info/ideas: Hudson now has a Gerrit plugin which does something similar. http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin Since Gerrit presents itself as a Git server, Hudson can easily check out the relevant branch, build it as normal, then uses its Gerrit user credentials to mark the change as "Verified" using Gerrit's API.
Should be possible with ReviewBot 1.0 now....
Yep, plus we have built-in integration with CircleCI and Travis CI, and Jenkins on the way. I think that's good enough to call this one "done"
-
- Confirmed + Fixed -
- Extensions