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 cruisecontrol-src-2.6.zip
- 00f5a224b26117e0840be5be7284fe43 *cruisecontrol-bin-2.5.zip
- 735d9325ab90fbd135cca4c21548c316 *cruisecontrol-src-2.5.zip
- 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/build.sh
- 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)
- java -jar dist/cruisecontrol.jar
Set up WORK_DIR
- 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
- Test it.
- 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
- This will differ per project, so it will be a good idea to attach some examples here.
- See the page at http://confluence.public.thoughtworks.org/display/CC/CruiseControl+Scheduling+Scenarios for examples of setting up schedules.
- This page may also be helpful, http://confluence.public.thoughtworks.org/display/CC/SchedulingExample.
- OPTIONAL: If you want the publishers to include unit test reports, make sure the XML files are merged into the logs.
Kick off the build loop!
- Most people will do this by running cruisecontrol.sh.
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
- Follow the instructions at http://confluence.public.thoughtworks.org/display/CC/Getting+Started+With+CruiseControl#GettingStartedWithCruiseControl-web.
- Note the comments regarding multi-project support when configuring the override.properties file.
- The build status file appears to be called "status.txt" now.
- The logs/ directory (or project subdirectory if this is multi-project) needs to be writable by the Tomcat process owner.
- The webapp creates a _cache directory under logs/ where it keeps its generated HTML.
- Explore the benefits of the artifactspublisher and the onfailure tag.
- http://confluence.public.thoughtworks.org/display/CC/Using+CruiseControl+with+Subversion <-- This page doesn't look that useful right now, but may improve in the future.