Randy's Wrapper Buildfile
Right now I'm using CC2.0. I use the CC buildfile as a wrapper for the buildfiles I use in my own source base. In my wrapper buildfile, I have a couple special targets for different test scenarios, targets for deleting and checking out my source base, a target for building an installer, and a target that doesn't do anything but set up the tomcat environment for webapp tests.
My CC buildfile is structured like this:
<project name="cc-build">
<target name="init">
</target>
<target name="clean" depends="init">
</target>
<target name="nuke" depends="init">
</target>
<target name="checkout" depends="nuke">
</target>
<target name="update" depends="clean">
</target>
<target name="cleancompile" depends="checkout">
</target>
<target name="testcompile" depends="update">
</target>
<target name="test" depends="testcompile">
</target>
<target name="dist" depends="cleancompile"/>
<target name="installer" depends="dist"/>
<target name="testdata" depends="test, fliptomcat">
</target>
<target name="fliptomcat">
</target>
<target name="masterbuild" depends="installer"/>
<target name="webtestbuild" depends="testdata"/>
<target name="testbuild" depends="test"/>
</project>
So, in my CC config file, I've got three schedules defined: two tests and one production. I've set one to run periodically in the middle of the night (the webapp testing one) and the other (the unit testing one) to run at each checkin. I've defined each scheduled build to use same buildfile, but different targets. I've also got a schedule that kicks off a masterbuild every fifth time around the build loop.
I've differentiated the three types of builds in a pretty simple way, here, but the important part is that targets like 'testbuild', 'webtestbuild' and 'masterbuild' mean something only to how I'm having cruisecontrol run the build. They only exist in this wrapper buildfile.
When I'm working on the source tree, I'm using other targets in other buildfiles. I'd never have a checkout target or a nuke target, for example, in a buildfile within my source tree.
Of all the targets here, the unit test, the clean, and the two compiles are the only ones I'd be using in the course of normal development. In real life, these CC buildfile targets point directly at the same targets I use when I'm coding.
My experience has been that once I had CC-level ANT buildfile targets that do the specialized work I want automated, that's all I needed. I didn't have to add anything to the buildfiles in my source tree.
By RandyNovick, 3-17-04
Jonathan's Wrapper Buildfile
As Randy does, I create a wrapper buildfile for every cruisecontrol project. The wrapper buildfile is only used by CC; I never use it in development. It contains targets to pull the project code out of code control, and then call into the "real" ant build file to do the building/deploying/testing.
<project name="wrapper-myproject" default="build" basedir="checkout">
<property name="cvs.repository" value=":local:/cvs"/>
<target name="getcode" description="Update packages from CVS">
<delete dir="myproject"/>
<cvs command="co myproject" cvsroot="${cvs.repository}" quiet="true"/>
</target>
<target name="build" depends="getcode" description="Build the project">
<ant antfile="build.xml" dir="myproject" target="all"/>
</target>
</project>
Note that under $CC_HOME I have a checkout dir and this buildfile manages the myproject dir inside of it. To ensure repeatable builds, this script removes the dir prior to getting a fresh copy from code control.
JonathanJulian 2004-05-24
Note that you don't HAVE to nuke your files everytime. In your wrapper you can do a CVS update.
<cvs cvsRoot=":pserver:User@host/path" command="update -P -d -C"
compression="true" failonerror="true"/>