Newbie question - passing blame downstream

[tec-3]

Hi,

I'm looking to use Hudson to improve the processes for a moderately large
and reasonably mature build project.  The existing (non-Hudson) system
checks out the code, builds it, and runs (a lot of) regression tests; all
on one host.

I'd like to have Hudson run the checkout and build on a single host and
then fan out the testing to a number of different hosts.  Doing the fan-out
with downstream projects seems easy enough, but one of the things that
would really be nice is to have the svn blame list available for the
downstream projects so when the regression tests fail the responsible
developers get notified.

Are there any examples of this type of system, or perhaps a Hudson
reference guide that shows how to set this up?  Or mailing list threads or
wiki pages that cover this?  Thanks for any pointers.

Best Wishes,

     --Tom



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[kohsuke]

tec@... wrote:

> Hi,
>
> I'm looking to use Hudson to improve the processes for a moderately large
> and reasonably mature build project.  The existing (non-Hudson) system
> checks out the code, builds it, and runs (a lot of) regression tests; all
> on one host.
>
> I'd like to have Hudson run the checkout and build on a single host and
> then fan out the testing to a number of different hosts.  Doing the fan-out
> with downstream projects seems easy enough, but one of the things that
> would really be nice is to have the svn blame list available for the
> downstream projects so when the regression tests fail the responsible
> developers get notified.

I think it would be relatively easy to write a plugin to do this, and I
think it would be very useful.

You first enable fingerprinting support on upstream and all downstream
projects, so that your test knows exactly which build it is testing.

Suppose a test regression is discovered. A "Publisher" (which you'll be
writing) can detect that, and through Hudson's internal object model,
you can figure out which build is being tested, and which build was last
tested.

 From there, you can also use the same object model and figure out who
made what changes to the builds. Then you can use the MailSender class
(or you could write your own code to talk to JavaMail if you know how
--- you can fine-tune e-mail contents that way) to fire off e-mails.

Add a little bit of UI hook up and you can also show that in the build page.


Would you be interested in giving a shot at writing something like this?
We can help you, and I think you'd only need to write exactly 3 classes
to get the minimal case working (and if you like it, you can grow it
from there.)

> Are there any examples of this type of system, or perhaps a Hudson
> reference guide that shows how to set this up?  Or mailing list threads or
> wiki pages that cover this?  Thanks for any pointers.
>
> Best Wishes,
>
>      --Tom
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@...

[tec-3]

Hi Kohsuke,

Sorry for the delayed response.

At the moment I'm trying to see what I can do with the existing Hudson
capabilities before I try to add new ones.  (I also haven't done any Java
coding in about 10 years.  :-)

If I can't get something workable with what's already available, I may come
back to this.  In the meantime I have more newbie questions, which I'll
post as separate messages.

Best Wishes,

     --Tom

Kohsuke Kawaguchi writes:
 > tec@... wrote:
 > > Hi,
 > >
 > > I'm looking to use Hudson to improve the processes for a moderately
 > > large and reasonably mature build project.  The existing (non-Hudson)
 > > system checks out the code, builds it, and runs (a lot of) regression
 > > tests; all on one host.
 > >
 > > I'd like to have Hudson run the checkout and build on a single host
 > > and then fan out the testing to a number of different hosts.  Doing
 > > the fan-out with downstream projects seems easy enough, but one of the
 > > things that would really be nice is to have the svn blame list
 > > available for the downstream projects so when the regression tests
 > > fail the responsible developers get notified.
 >
 > I think it would be relatively easy to write a plugin to do this, and I
 > think it would be very useful.
 >
 > You first enable fingerprinting support on upstream and all downstream
 > projects, so that your test knows exactly which build it is testing.
 >
 > Suppose a test regression is discovered. A "Publisher" (which you'll be
 > writing) can detect that, and through Hudson's internal object model,
 > you can figure out which build is being tested, and which build was last
 > tested.
 >
 >  From there, you can also use the same object model and figure out who
 > made what changes to the builds. Then you can use the MailSender class
 > (or you could write your own code to talk to JavaMail if you know how
 > --- you can fine-tune e-mail contents that way) to fire off e-mails.
 >
 > Add a little bit of UI hook up and you can also show that in the build page.
 >
 >
 > Would you be interested in giving a shot at writing something like this?
 > We can help you, and I think you'd only need to write exactly 3 classes
 > to get the minimal case working (and if you like it, you can grow it
 > from there.)
 >
 >
 > > Are there any examples of this type of system, or perhaps a Hudson
 > > reference guide that shows how to set this up?  Or mailing list threads or
 > > wiki pages that cover this?  Thanks for any pointers.
 > >
 > > Best Wishes,
 > >
 > >      --Tom
 > >
 > >
 > >
 > > ---------------------------------------------------------------------
 > > To unsubscribe, e-mail: users-unsubscribe@...
 > > For additional commands, e-mail: users-help@...
 > >
 > >
 >
 >
 > --
 > Kohsuke Kawaguchi
 > Sun Microsystems                   kohsuke.kawaguchi@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...