www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Running hudson or something like it on changes before they are committed
Date Tue, 28 Sep 2010 00:33:36 GMT
I talked some with Benson off-list.

It seems that he does indeed want a pre-commit builder.  This is similar in
intent to the system used in Hadoop and related projects where adding a
patch to JIRA triggers a build.

There would be several ways to skin Benson's cat.  Something along the lines
he is suggesting would be to give him permission to create hudson jobs (I
think his PMC can do this).  Then he could create a change detecting hudson
job that builds against a github branch where his changes are.  When he is
ready, he can commit and normal processes take over (and he deletes his
hudson build, of course).

Another approach would be to have him publish patches to JIRA from git.
 That is a bit of a pain, but doable and is a more general mechanism for
other developers.  It would be nice if the hudson patch plugin could
recognize references to git branches.  Referencing the github apache mirrors
should make this possible.

He is also looking at the web services API to hudson.  THat might allow
scripted creation of a one-off hudson job to do the deed.

On Mon, Sep 27, 2010 at 5:17 PM, Gav... <gavin@16degrees.com.au> wrote:

> > -----Original Message-----
> > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > Sent: Tuesday, 28 September 2010 8:59 AM
> > To: infra@apache.org
> > Subject: Running hudson or something like it on changes before they are
> > committed
> >
> > A full test run of Apache CXF on even a moderately powerful dev
> > machine takes a good long time, and I'm sure that CXF is not alone or
> > even first in line here.
> >
> > There are commercial CI systems that allow 'preflight' of changes. It
> > seems to me that it should be possible to assemble something out of
> > GIT and hudson that could do the job.
> >
> > A job would consist of a commit ID against one of the GIT mirrors and
> > an email-formatted patch. It would clone the mirror, apply the patch,
> > run a build, and email the results to the originator.
> >
> > I suspect that a hudson plugin would have to come into existence to
> > organize all of this. It is also possible that this could be done via
> > some other thing that used the hudson web service API to trigger a
> > build using only existing hudson pieces. Outside of hudson, it could
> > apply the patch to a git branch on the existing git.apache.org mirror
> > of interest, and then create the job.
> >
> > Or, would it be possible to give ASF committers sufficient access to
> > (a) push branches to git.apache.org and (b) create one-shot hudson
> > jobs? That would turn all this into a tool instead of a service.
> >
> > I would try to make some time to build this technology if infra had
> > any sympathy for the notion of deploying it if I ever got it to work.
> Let me see if I got this correct.
> You want to test your patches work using Hudson/Git before then committing
> the
> patch to svn that then triggers Hudson again to build it again??
> The point of a Build system is to test code and notify the project if a
> build
> fails, what you want is something to test your patch before this happens so
> that when you commit it will not fail the build proper.
> I'm not getting the point.
> Either way please take your question to the more focused builds@ list.
> Gav...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message