Skip to end of metadata
Go to start of metadata

Quick Start

Initial set up

  • Download cruisecontrol source zip, at the time of this edit, the latest is cruisecontrol 2.6.
  • Check the md5sum. The distribution site doesn't appear to have checksums available for their files, but here are the checksums for the ones I downloaded.
    • 95e5d092245cc304237b55ac77e4cf34
    • 00f5a224b26117e0840be5be7284fe43 *
    • 735d9325ab90fbd135cca4c21548c316 *
  • Unzip to INSTALL_DIR. This directory will differ for different sysadmins, but for me, for testing, INSTALL_DIR=~/java/cruisecontrol-2.5.
  • Build it.
    • sh main/
    • This will compile, run the unit tests, build the jars.
    • When I ran it, the build succeeded, but not all of the unit tests passed.
  • Test it.
    • java -jar dist/cruisecontrol.jar
      • NOTE: In CC 2.6, you need to run cruisecontrol-launcher.jar.
    • If successful, you will see that the "build started" and a cruisecontrol.log (remove this)


  • Create WORK_DIR. Again, this directory will vary, but for testing purposes, WORK_DIR=~/tmp/cc-work for me.
  • mkdir checkout logs artifacts
  • Create minimal config.xml
    • <cruisecontrol></cruisecontrol>
  • Test it.
    • ~/java/cruisecontrol-2.5/main/bin/
    • Examine standard output and cruisecontrol.log for errors. We expect that CC runs, but doesn't find a config file.

Set up your project build file

  • Create build-<your project>.xml file. For example, during testing, I wrote a build-scratch-jelai.xml file.
    • If you adhere to the philosophy put forth in the continuous integration paper, this build file should (a) remove any previous checkout, (b) check out a fresh working copy from the repository, and (c) call the ant target(s) that compile and test the project.
  • Test the build file.
    • ant -buildfile <name of build file>
  • OPTIONAL: If you want the publishers to include unit test reports, be sure that these are available as XML files.

Set up the config.xml file

Kick off the build loop!

  • Most people will do this by running


Creating a read-only cruise control user to check out from anonymous repositories

In Subversion this can be accomplished using svn:// + svnserve.conf + authz.

Creating a cruise control user to run the build process

Create ccadmin user.

  • Should this user be able to log in? At the console? Through ssh?
  • Should this user have a shell?
  • Should the account be disabled? Should a real password be set?
  • sshd_config AllowUser
  • What about interactions with screen + su ccadmin + /dev/pts permissions.
  • Should we configure sudo so that regular users can run the cruisecontrol process as user ccadmin.

Create /home/cruisecontrol directory (owned by ccadmin.users) to host build-related files.

  • Need to set up .bashrc with JAVA_HOME ANT_HOME PATH

What should you commit to the version control repository?

The Pragmatic Automation book (and common sense) suggests that the config.xml and cc-build.xml files should be committed to version control. However, there is not much guidance beyond that. Here are a few possible scenarios:

  • Commit just those two files to a project subdirectory (like resources/cc).
  • Commit everything under the workspace per project (e.g. /home/cruisecontrol/workspace/hdbstat would be a working copy from the repository where checkout/ and logs/ would be empty stubs)
  • Commit everything under /home/cruisecontrol (except the binary distribution of the cruise control application).

Consider whether you will build multiple times within a single project. For example, you might want to build the trunk and also a few release branches. Also consider whether you would create a multi-project config.xml.

Configuring the webapp


  • None