CI with CruiseControl and clearcase

Continuous Integration with CruiseControl 2.7.1 and ClearCase

Abstract

Step-by-step installation of CruiseControl in Solaris 9 with ClearCase. This post details instructions on how to setup CruiseControl build directory in a flexible way and to write advanced CruiseControl project configuration files using plugins. Using the installation directory setup explained here we can run two continuous integration streams using 2 instances of CruiseControl running on 1 host machine. This installation guide can be suited to Windows machine with little efforts.

Common problems with solutions are listed at the end of this post.

Build environment and machine specs

The host machine architecture is SPARC with 2GB physical memory running Solaris 9, the SCM we are using is ClearCase.

Part 1: Installation and Directory Setup

Define two variables :
Let CC_INSTALL equal to /opt/cc2
and let CC_HOME equal to /opt/cc2/cruisecontrol-bin-2.7.1

Now download cruisecontrol 2.7.1 binary and extract it to /opt/cc2/cruisecontrol-bin-2.71

Create clearcase view for each product development streams (assuming you have not already created storage location for the views called asantoso_views, here I use asantoso_views storage location tag, and I have two ClearCase views to be integrated with CruiseControl):

% cleartool mkstgloc -view asantoso_views /private/asantoso/viewstore

% cleartool mkview -tag apc_cruisecontrol_3.0_stream1 -stgloc asantoso_views
% cleartool mkview -tag apc_cruisecontrol_3.0_stream2 -stgloc asantoso_views

We structure our directory like this (s1 and s2 are my stream names):

/opt/cc2
/opt/cc2/cruisecontrol-bin-2.7.1
/opt/cc2/streams/s1
/opt/cc2/streams/s1/logs
/opt/cc2/streams/s1/configs
/opt/cc2/streams/s2
/opt/cc2/streams/s2/logs
/opt/cc2/streams/s2/configs
Create this structure and set the directory read and write permissions to your user id.

The motivation using this setup:

• Upgrading to a new version of CruiseControl is a snap, just replace cruisecontrol-bin-2.7.1 and update the necessary path variables in file $CC_HOME/streams/s1/start.sh
• CruiseControl serializes a project into .ser file and as of 2.7.1 there’s no way to specify where the .ser files are stored, by default it is stored in the context where CruiseControl is started.
• We will have start.sh script in $CC_HOME/streams/s1 which executes CruiseControl so that the .ser files will be stored in there.
• We will store our configuration files in the $CC_HOME/streams/s1/configs directory and the build logs of each CruiseControl projects will be stored in $CC_HOME/streams/s1/logs directory
  The CruiseControl server log will be stored in $CC_HOME/streams/s1.

Now, create start.sh in $CC_HOME/streams/s1

#!/bin/bash

CC_INSTALL=/opt/cc2

CC_HOME=$CC_INSTALL/cruisecontrol-bin-2.7.1
CC_LOGS=$CC_INSTALL/streams/s1/logs
CC_CONFIG=$CC_INSTALL/streams/s1/configs/config.xml
CC_RMIPORT=1111
CC_WEBPORT=8081
CC_JMXPORT=8000
CC_NAME=APC_STREAM1

CLEARCASE_HOME=/opt/rational/clearcase/bin

PATH=$JAVA_HOME/bin:$CC_HOME:$PATH:$CLEARCASE_HOME
export PATH

cleartool startview apc_cruisecontrol_3.0_stream1

cruisecontrol.sh -jmxport $CC_JMXPORT -rmiport $CC_RMIPORT -cchome $CC_HOME
-webport $CC_WEBPORT -logDir $CC_LOGS $* -configfile $CC_CONFIG -ccname $CC_NAME

CruiseControl launcher options (case sensitive):

• -jmxport : jmx port
• -rmiport : rmi port
• -webport : jetty http server port
• -cchome : path to cc binary
• -logDir : path to base log directory where each CruiseControl project’s log is stored, if relative path is specifed, it is evaluated relative to context where CC is started.
• -configfile : the entry configuration file
• -ccname : the name to be displayed on jsp build reports page

Make sure you have JAVA_HOME environment variable set correctly.

The procedure for setting CC for second stream is nearly identical to the first, we need to assign distinct port and path values.

Open cruisecontrol.sh in $CC_HOME, add or modify the following lines on appropriate locations

Remove the line

CCDIR=`pwd`

Specify the cruisecontrol binary directory

CCDIR=`dirname $0`
export CCDIR

Optional step: delete the last two lines

$EXEC &
echo $! > cc.pid

Optional step: add two lines at the end of file

echo $EXEC
exec $EXEC

Uncomment CC_OPTS variable, allocate large JVM initial and maximum heap size depending on size of the host machine’s memory,

-Xms256m -Xmx1024m

Note that CruiseControl itself does not consume huge memory to run, but if you do not use fork in javac task it is advisable to set enough memory for CruiseControl

Part 2: CruiseControl Configuration File

Create config.xml in $CC_HOME/streams/s1

Lastly we include main.xml which is to define project templates.

Part 3: Configuration Templates and CruiseControl plugins

Create main.xml in $CC_HOME/streams/s1/configs
From this point on, it is specific to the type of projects that you have. In my case:
I have to abstract out the possible build project into three: periodic, manual, and timed into build templates through the use of CruiseControl plugins. The combination of using plugins and extraction of all the configuration values from these templates allows me to (for example) set the default email to be notified across all projects by modifying one property and furthermore I can set add email to be notified to a specific project.

Note: Similarly in here, if relative value is used in saveLogDir attribute, the path is evaluated from the context of where CC is started.
For example: If CC is started in /opt/cc2/streams/s1 by calling start.sh and saveLogDir value is logs then the final path is /opt/cc2/streams/s1/logs

A little thing to point at that in my build configuration contains the Apache Ivy ant task elements.

Last on the bottom we include projects.xml

Part 4: Projects configuration

Create projects.xml in $CC_HOME/streams/s1/configs

Note that we can override the template and/or properties defined earlier in the parent config file but still bound to the context of the child config. The overriden template will still use properties in the parent config file unless overriden in the child.

Notice two important things:

• In integration nightly project I am overriding child elements of a template.
• I am overriding the global properties: project.periodic.components.dir and project.periodic.build.target to be used by the projects in this file. If I override one of the property twice or more, the last declared property will be used. This means that the order which the properties appear does not matter.

Common Problems and Solutions

• Invalid email user
  As far as 2.7.1 is concerned, when you click on the JSP build button, CC generates one fake modification created by fake “user” and it will send email to this address “user@mailhost” which is most probably does not exist. One way to suppress this is by adding as a child of the email publisher, another way is by mapping this user to a valid email address
• Time based build operates as a periodic build if declared inside a composite element.
  One solution is to create time based build as a separate project.
• logDir not found
  First note the context where CC is started, check the validity of the path -logDir and subsequently the validity of saveLogDir attribute value of the antbuilder. If relative path is used in saveLogDir the path is relative to the context of -logDir, and lastly check if read/write permission are set correctly.
• Killing CruiseControl JMX
  If some reasons, the JMX server is not terminated and stays in background you can kill its process
  get the pid by typing: ps -ef | grep mx4j