The CruiseControl Configuration Block¶

The root tag in the Server Configuration file is the <cruisecontrol> tag. This can contain 1 or many Project Configuration Blocks.

Example:

 1<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
 2    <project name="P1">
 3        <other settings />
 4    </project>
 5
 6    <project name="P2">
 7        <other settings />
 8    </project>
 9
10</cruisecontrol>

Reducing Configuration Duplication¶

From CCNet 1.4 onwards, there is a Configuration_Preprocessor (that's why there is the cb namespace declared in the root tag), which allows you to use variables and the like inside the ccnet.config file. Look at the Configuration_Preprocessor for more information about this.

Before CCNet 1.4, the following technique is a solution.
As you add more projects to your ccnet.config file, you may end up with considerable duplication across configuration elements. This can make it a hassle to maintain your projects as you have to update the same settings in many places.

You can achieve some degree of reuse by using DTD entities.
The example below demonstrates how you can create an entity to represent the cvs source control block so that it can be shared across two projects:

 1<!DOCTYPE cruisecontrol [
 2    <!ENTITY sc "<sourcecontrol type='cvs'>
 3        <executable>c:\cvs\cvs.exe</executable>
 4    </sourcecontrol>">
 5]>
 6<cruisecontrol>
 7    <project name="project1">
 8        &sc;
 9    </project>
10    <project name="project2">
11        &sc;
12    </project>
13</cruisecontrol>

You can also use DTD entity notation to split your ccnet.config file into multiple smaller xml files. This can help you reduce duplication and can simplify the maintenance of certain configuration elements. The following example demonstrates how the configuration for two CCNet project project1 and project2 can be read in from separate files.

1<!DOCTYPE cruisecontrol [
2    <!ENTITY project1 SYSTEM "file:project1.xml">
3    <!ENTITY project2 SYSTEM "file:project2.xml">
4]>
5<cruisecontrol>
6  &project1;
7  &project2;
8</cruisecontrol>

The same approach should work at any level in the ccnet.config file. For example, email users and aliases can be managed in an external file:

 1<!DOCTYPE cruisecontrol [
 2    <!ENTITY email SYSTEM "file:email.xml">
 3]>
 4<cruisecontrol>
 5    <project name="project1">
 6        <publishers>
 7            &email;
 8            <xmllogger />
 9        </publishers>
10    </project>
11</cruisecontrol>

One limitation of this approach is that these external files will not be monitored by the CCNet server. Hence, CCNet will not automatically reload the configuration when these files change. The ccnet.config file will need to be touched for these files to be reloaded.