Re: Running hudson or something like it on changes before they are committed

[Ted Dunning <te...@gmail.com>]

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... <ga...@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...
>
>
>
>

Re: Running hudson or something like it on changes before they are committed

[Benson Margulies <bi...@gmail.com>]

On Mon, Sep 27, 2010 at 9:15 PM, Jesse Glick <je...@oracle.com> wrote:
> On 09/27/2010 08:33 PM, Ted Dunning wrote:
>>
>> It seems that he does indeed want a pre-commit builder.
>
> FYI:
>
> http://wiki.hudson-ci.org/display/HUDSON/Designing+pre-tested+commit

Yes, I'm aware of this. A really comprensive version of this idea
would need to be hashed out on the banks of the Hudson. Perhaps the
hadoop thing is more than sufficient, or perhaps me 'gitty' variation
on it would have significant advantages.

>
> There does not seem to be any broad consensus on what such a feature should
> look like, at least if implemented within Hudson itself rather than hacked
> up as part of a site's installation.
>

Re: Running hudson or something like it on changes before they are committed

[Jesse Glick <je...@oracle.com>]

On 09/27/2010 08:33 PM, Ted Dunning wrote:
> It seems that he does indeed want a pre-commit builder.

FYI:

http://wiki.hudson-ci.org/display/HUDSON/Designing+pre-tested+commit

There does not seem to be any broad consensus on what such a feature should look like, at least if implemented within Hudson itself rather than hacked up as part of a 
site's installation.

Re: Running hudson or something like it on changes before they are committed

[Benson Margulies <bi...@gmail.com>]

I have as requested created a replacement thread on builds@ where you
all can apply track shoes as needed, and I'm not commenting further
here.

On Mon, Sep 27, 2010 at 8:33 PM, Ted Dunning <te...@gmail.com> wrote:
> 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... <ga...@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...
>>
>>
>>
>>
>