search

sureshvv / reviewboard

Automatically exported from code.google.com/p/reviewboard
0 stars 0 forks source link

integration with buildbot like systems #88

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by dsvens...@gmail.com on 3 Jun 2007 at 10:00

GoogleCodeExporter commented 9 years ago

Original comment by trowb...@gmail.com on 3 Jun 2007 at 10:33

GoogleCodeExporter commented 9 years ago 
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."

Original comment by chip...@gmail.com on 4 Jun 2007 at 8:08

GoogleCodeExporter commented 9 years ago 
+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..

Original comment by daniel.l...@gmail.com on 29 Jun 2007 at 2:20

GoogleCodeExporter commented 9 years ago

Original comment by chip...@gmail.com on 11 Nov 2007 at 5:09

GoogleCodeExporter commented 9 years ago

Original comment by chip...@gmail.com on 23 Dec 2007 at 7:16

GoogleCodeExporter commented 9 years ago

Original comment by trowb...@gmail.com on 28 Sep 2008 at 10:47

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ted.dunn...@gmail.com on 16 Feb 2009 at 9:20

GoogleCodeExporter commented 9 years ago 
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.

Original comment by br...@frogmouth.net on 2 Jan 2010 at 7:50

GoogleCodeExporter commented 9 years ago 
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.

Original comment by chris@orr.me.uk on 13 Apr 2010 at 2:11