Continuous integration tools - JUnit in Action - page 175

The listeners element D is used mainly to enlist different pluggable listener
instances. These listeners are notified of every project build event (like the start or
end of the project). For instance, in our config.xml we define a currentbuild-
statuslistener , which we use to write the project's statuses in a file, specified by
the file attribute.
Listeners in CruiseControl are interesting creatures, so we'd like here to spend a
few lines on them. As you've probably noticed, building the project on a regular
schedule wastes a lot of resources. CruiseControl is smart in that it doesn't fire a new
build unless it detects some changes in the source control system. Otherwise, the
build would be pointless, because we'd get the same results. But how do we distinguish
whether the CruiseControl server was up and skipped the build because there were no
changes in the source control system or the server was down? The solution is the lis-
teners. You can configure CruiseControl's listeners to log everything in a file, some-
where on the filesystem. The upside is that the events that activate the listeners are
triggered regardless of the state of the source control system. This way you can keep
track of whether a build was attempted.
The next thing in our config.xml is the bootstrappers element E . This is a con-
tainer element to define some actions that need to be taken before the build is exe-
cuted. Again, the bootstrappers are run regardless of whether a build is necessary or
not. In our config file we've specified an antbootstrapper F that will invoke the
clean target of our project's build descriptor and will clean all the resources we've
used during the previous build.
The modificationset element G defines the sets of files and folders that Cruise-
Control will monitor for changes. One thing to remember here is that the build is
attempted only when a change is detected on any of the sets listed in the modifica-
tionset element.
The schedule element H is the one that schedules the build. The interval
parameter specifies the build time interval (in seconds), and inside the schedule ele-
ment we list the type of build system we're using. We need to specify the home folder
of the build system and also the buildfile to execute. In our config file we've specified
Ant, but you can use Maven without any problems as well.
The log section I is optional and is used to specify where the logs of the execu-
tion should be stored. The merge element inside it tells CruiseControl which logs of
the build execution are valuable and should be stored in the log directory of the
CruiseControl execution. In our example, we only care about the .xml files from the
JU nit execution, so we're going to store them in the log folder.
The last section is the publishers section J , and it's used to make the final steps
of the scheduled build. The same ways the bootstrappers are executed every time
before the build, the publishers are executed every time after the build, regardless of the
result of the build. In publishers we can specify what whistles are blown as the build
finishes. It could be sending an email, publishing the produced artifacts somewhere
on the internet, or posting a message on the Jabber Messenger. In the example shown