Nice !
Yeah, Chris - that's something like what I'm talking about - here is how
I understand it works.
A number of clients are set up with different build environments and/or
build targets, or even versions e.g. MAIN and 2.4 and 3.0
They run a script that loops infinitely with a pause (0-???) between
builds.
They check out or refresh a tree from the Tinderbox/CVS (I'm not sure if
this has to be the same host - but I suspect so) server, mail the
tinderbox server saying who they are and what they intend to do etc...
They do a build then mail the server the results.
The server builds a nice results page with a table of platforms against
time.
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports
in a realtime situation you can get pretty swift feedback as to whether
you have broken anything on any platform.
The idea is that after checking in code you make yourself available
until you can see that all builds are green, then you are free to go to
bed.
Anyone wanting to check out a working tree can just look back up the
timeline for the last successful build and check it out.
If a build is broken, tinderbox tries to figure out which file broke and
who was responsible. Peer pressure should soon put a stop to people
breaking the build !
I think simply having someone checking your changes out, building them
and letting you know if they worked on another machine is pretty
reassuring in itself.
I'll keep the list informed of my findings. We should probably talk some
more soon if you are interested. It shouldn't be hard to find lots of
people to volunteer to be tinderbox clients, but the tinderbox server
might be a bit trickier. My main concern at the moment is that tinderbox
expects direct access to the CVS repository, and that is on SourceForge,
so we may have to mirror it....
Thanks for your interest,
Jules
Chris Kimpton wrote:
> Hi,
>
> I am sort of doing something towards this now.
>
> The site http://lubega.com is produced by an automated
> daily script that does a cvs update and then a rebuild
> and test of the jboss/jbosstest code.
>
> It only covers 1 platform/JVM - 386Linux2.2, Sun JVM
> 1.3.
>
> I could fairly easily add alternate builds with
> different linux jvms.
>
> I guess the real work is in ensuring the tests provide
> good coverage and ensuring they work consistently -
> the current jmsra ones seem to switch between failing
> and working at random...
>
> And then there is setting up a tinderbox server...
>
> What kind of bandwidth requirements do you see being
> needed? Can tinderbox work off a daily rebuild or
> does it need to happen "realtime" as code is checked
> in? Although I guess intraday updates of the tree
> should not eat much bandwidth...
>
> Chris
>
> PS
>
> > >
> > > http://www.mozilla.org/tinderbox.html
> > >
> > >
>
> I must read more about tinderbox...
>
> =====
> Need somewhere to Live in London - http://freeflats.com
>
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35
> a year! http://personal.mail.yahoo.com/
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
