Re: Running hudson or something like it on changes before they are committed
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... 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... > > > >
preflight idea
In some 'day job' environments I've worked in, the infrastructure included a 'pre-flight' automated build option. I think it would be valuable to add this to the ASF infrastructure, at least for the Java side of the Universe (where I see a relatively easy way to do it). What's that? A way to ask a build server to apply a patch and run a full build. The most extreme version of this scheme is one in which a patch must pass a pre-flight test before it is committed to source control. That's not my proposal. Rather, I'm looking for a way to use shared servers to run lengthy test suites before the commit. Why would someone like to do this? As soon as I commit to the trunk, other developers are prone to pull down my changes and be inconvenienced if I made a mistake. On the other hand, I've only got so much computer available for testing ASF changes, so I'd like to be able to do more extensive testing on an ASF hudson instance. Also, some things have to be qualified against multiple JVMs. My personal macbook, for example, can't easily test with 1.5, since Apple flushed the 1.5 JVM from SnowLeopard. Could I do something like this with existing facilities? Yes, I could. I could make a sandbox branch, and a hudson job to build it. However, that does not scale so well to many other people doing the same thing, and I personally find it inelegant. What 'infra' would it take to make this fly? The existing infrastructure is actually very close to this. Consider the git mirrors at git.apache.org. If committers were permitted to create branches on there, and if committers were permitted to use the hudson web service API to create one-time jobs, and if the hudson git plugin were installed, then any committer (or any committer filtered by their PMC) could push a change to a git server and start a hudson job to build it. The purpose of this email is to measure interest / sympathy in this idea. If everyone else things it's pointless, I'm not about to go on a campaign to drum up support.
Re: Running hudson or something like it on changes before they are committed
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 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... 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... >> >> >> >> >
Re: preflight idea
How is this different from the Hadoop patch plugin? There, patches added to JIRA are checked out and built with problems reported back to JIRA. On Mon, Sep 27, 2010 at 5:43 PM, Benson Margulies wrote: > In some 'day job' environments I've worked in, the infrastructure > included a 'pre-flight' automated build option. I think it would be > valuable to add this to the ASF infrastructure, at least for the Java > side of the Universe (where I see a relatively easy way to do it). > > What's that? > > A way to ask a build server to apply a patch and run a full build. > > The most extreme version of this scheme is one in which a patch must > pass a pre-flight test before it is committed to source control. > That's not my proposal. Rather, I'm looking for a way to use shared > servers to run lengthy test suites before the commit. > > Why would someone like to do this? > > As soon as I commit to the trunk, other developers are prone to pull > down my changes and be inconvenienced if I made a mistake. On the > other hand, I've only got so much computer available for testing ASF > changes, so I'd like to be able to do more extensive testing on an ASF > hudson instance. Also, some things have to be qualified against > multiple JVMs. My personal macbook, for example, can't easily test > with 1.5, since Apple flushed the 1.5 JVM from SnowLeopard. > > Could I do something like this with existing facilities? > > Yes, I could. I could make a sandbox branch, and a hudson job to build > it. However, that does not scale so well to many other people doing > the same thing, and I personally find it inelegant. > > What 'infra' would it take to make this fly? > > The existing infrastructure is actually very close to this. Consider > the git mirrors at git.apache.org. If committers were permitted to > create branches on there, and if committers were permitted to use the > hudson web service API to create one-time jobs, and if the hudson git > plugin were installed, then any committer (or any committer filtered > by their PMC) could push a change to a git server and start a hudson > job to build it. > > The purpose of this email is to measure interest / sympathy in this > idea. If everyone else things it's pointless, I'm not about to go on a > campaign to drum up support. >
Re: Running hudson or something like it on changes before they are committed
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: preflight idea
I didn't know about the Hadoop patch plugin until I read your message, and I didn't read your message until after I posted this new thread. If that is easily shoveled around to other projects then it probably does everything I am looking to do. On Mon, Sep 27, 2010 at 8:47 PM, Ted Dunning wrote: > How is this different from the Hadoop patch plugin? There, patches added to > JIRA are checked out and built with problems reported back to JIRA. > > On Mon, Sep 27, 2010 at 5:43 PM, Benson Margulies > wrote: > >> In some 'day job' environments I've worked in, the infrastructure >> included a 'pre-flight' automated build option. I think it would be >> valuable to add this to the ASF infrastructure, at least for the Java >> side of the Universe (where I see a relatively easy way to do it). >> >> What's that? >> >> A way to ask a build server to apply a patch and run a full build. >> >> The most extreme version of this scheme is one in which a patch must >> pass a pre-flight test before it is committed to source control. >> That's not my proposal. Rather, I'm looking for a way to use shared >> servers to run lengthy test suites before the commit. >> >> Why would someone like to do this? >> >> As soon as I commit to the trunk, other developers are prone to pull >> down my changes and be inconvenienced if I made a mistake. On the >> other hand, I've only got so much computer available for testing ASF >> changes, so I'd like to be able to do more extensive testing on an ASF >> hudson instance. Also, some things have to be qualified against >> multiple JVMs. My personal macbook, for example, can't easily test >> with 1.5, since Apple flushed the 1.5 JVM from SnowLeopard. >> >> Could I do something like this with existing facilities? >> >> Yes, I could. I could make a sandbox branch, and a hudson job to build >> it. However, that does not scale so well to many other people doing >> the same thing, and I personally find it inelegant. >> >> What 'infra' would it take to make this fly? >> >> The existing infrastructure is actually very close to this. Consider >> the git mirrors at git.apache.org. If committers were permitted to >> create branches on there, and if committers were permitted to use the >> hudson web service API to create one-time jobs, and if the hudson git >> plugin were installed, then any committer (or any committer filtered >> by their PMC) could push a change to a git server and start a hudson >> job to build it. >> >> The purpose of this email is to measure interest / sympathy in this >> idea. If everyone else things it's pointless, I'm not about to go on a >> campaign to drum up support. >> >
Re: Running hudson or something like it on changes before they are committed
On Mon, Sep 27, 2010 at 9:15 PM, Jesse Glick 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: preflight idea
Several sites are using it so it must be pretty easy. Hama for one. On Mon, Sep 27, 2010 at 6:27 PM, Benson Margulies wrote: > I didn't know about the Hadoop patch plugin until I read your message, > and I didn't read your message until after I posted this new thread. > If that is easily shoveled around to other projects then it probably > does everything I am looking to do. > > On Mon, Sep 27, 2010 at 8:47 PM, Ted Dunning > wrote: > > How is this different from the Hadoop patch plugin? There, patches added > to > > JIRA are checked out and built with problems reported back to JIRA. > > > > On Mon, Sep 27, 2010 at 5:43 PM, Benson Margulies >wrote: > > > >> In some 'day job' environments I've worked in, the infrastructure > >> included a 'pre-flight' automated build option. I think it would be > >> valuable to add this to the ASF infrastructure, at least for the Java > >> side of the Universe (where I see a relatively easy way to do it). > >> > >> What's that? > >> > >> A way to ask a build server to apply a patch and run a full build. > >> > >> The most extreme version of this scheme is one in which a patch must > >> pass a pre-flight test before it is committed to source control. > >> That's not my proposal. Rather, I'm looking for a way to use shared > >> servers to run lengthy test suites before the commit. > >> > >> Why would someone like to do this? > >> > >> As soon as I commit to the trunk, other developers are prone to pull > >> down my changes and be inconvenienced if I made a mistake. On the > >> other hand, I've only got so much computer available for testing ASF > >> changes, so I'd like to be able to do more extensive testing on an ASF > >> hudson instance. Also, some things have to be qualified against > >> multiple JVMs. My personal macbook, for example, can't easily test > >> with 1.5, since Apple flushed the 1.5 JVM from SnowLeopard. > >> > >> Could I do something like this with existing facilities? > >> > >> Yes, I could. I could make a sandbox branch, and a hudson job to build > >> it. However, that does not scale so well to many other people doing > >> the same thing, and I personally find it inelegant. > >> > >> What 'infra' would it take to make this fly? > >> > >> The existing infrastructure is actually very close to this. Consider > >> the git mirrors at git.apache.org. If committers were permitted to > >> create branches on there, and if committers were permitted to use the > >> hudson web service API to create one-time jobs, and if the hudson git > >> plugin were installed, then any committer (or any committer filtered > >> by their PMC) could push a change to a git server and start a hudson > >> job to build it. > >> > >> The purpose of this email is to measure interest / sympathy in this > >> idea. If everyone else things it's pointless, I'm not about to go on a > >> campaign to drum up support. > >> > > >
