Comments below...
-----------------------------------------------------------------
Jeffrey D. Brekke Quad/Graphics
[EMAIL PROTECTED] http://www.qg.com
-----------------------------------------------------------------
> -----Original Message-----
> From: Warren Janssens [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, August 25, 2001 3:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: CruiseControl
>
>
> I've been the in charge of cruise control for the
> project I'm working on an I have to say I'm not too
> impressed with it.
>
> It doesn't add any value over just using ant and a
> cron job. The requirement for a servlet container is
> useless, the xsl provided doesn't tell you any useful
> information so you end up rolling your own anyways.
The goal here is continuous integration, not automation of daily/nightly
builds.
What it gives us is the ability to monitor our CVS repo and kick a build off
when changes are committed.
XSL sucks, IMO, but there is a move to seperate the tech used for the view
portion of the reporting subsystem. The servlet is there to allow a visual
representation of the build instead of reading a log file.
> The only thing it really gives you is the ability to
> track who made changes since the last build but this
> is useless IMO. It is supposed to be a blame system
> but doesn't work when there is lots of activity.
It is not a blame system or a build scheduler. It is a continuous
integration system, or at least is striving to be. The goal is to integrate
committed changes all the time. It is not a daily ( insert other increment
here if you like ) build system.
> Also the custom label incrementer support doesn't work
> well with dates (IMHO) and you have very poor control
> over when builds happen, especially if you are commit
> happy (like me). Also, if your builds are failing you
> get spammed with failures over the weekend (even with
> no CVS activity).
You can control the label incrementer anyway you want, since it is
pluggable, I just created one for CVS and contrib'd it. The spamming issue
was recently fixed and allows much greater control over when email is sent.
The CC team is prepping another release with all these features, until then
you could check it out from CVS.
> I haven't used GUMP yet but from my lurking here I
> believe it to be superiour to CC.
I attempted to use GUMP internally here a few months back before using CC
and it just wasn't ready for general use. GUMP's multi-project stuff is
awesome and something that CC really needs. I believe the two could work
together, combining the continuous integration features that CC needs with
GUMP's project defs and build stuff.
> Sorry to be critical of the CC project but I believe
> it is on the wrong track.
I think CC is right 'on track' for a continuous integration tool. If
automating your daily and nightly builds is all your looking for, then I can
see why CC seems akward.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
