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: preflight idea
Date Tue, 28 Sep 2010 00:47:10 GMT
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 <bimargulies@gmail.com>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.
>

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