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 <ted.dunn...@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:bimargul...@gmail.com] >> > Sent: Tuesday, 28 September 2010 8:59 AM >> > To: in...@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... >> >> >> >> >
