ConfigureCruiseControl
Pages 207
General
- Wiki Home
- FAQ Frequently asked questions
- Examples
- Presentations
- PhilosophyAndVision
- Best practices for using Umple
- Publications and theses
- Tutorials
- Installing Eclipse plugin
Developers
- Developer Setup
- UmpleOnline Setup
- Contribution Process
- Architecture
- Cheat sheet
- Umpleonline manual tests
- Planned development
- DraftManualPages
Server maintenance
External
Other
Clone this wiki locally
Installing Capistrano
We created a capistrano task for deploying cruise control the server. From umple_configs, you simply type (this only needs to be run once per "server", and is left here for documentation purposes should you need to configure another CC server).
cap install:cc
Under the hood this does the following:
cd /h/ralph/umple_configs/src/ && unzip cruisecontrol-bin-2.8.4
cd /h/ralph/umple_configs/src/cruisecontrol-bin-2.8.4/ && mv config.xml config.xml.original
ln -fs /h/ralph/umple_configs/src/cruisecontrol-bin-2.8.4 /h/ralph/umple_configs/bin/cc
ln -fs /h/ralph/umple_configs/config/cc_config.xml /h/ralph/umple_configs/bin/cc/config.xml
mkdir /h/ralph/umple_configs/bin/cc/logs/Umple
In essence, unzip the file, overwrite the config files based on umple_configs and create the necessary project directories.
The CC config.xml
The first file of interest is the config.xml, which is stored in the umple_configs under ./config/cc_config.xml. As of April 5, 2011, it contained the following. Note this was later changed to use git.
<cruisecontrol>
<project name="Umple" buildafterfailed="no">
<listeners>
<currentbuildstatuslistener file="/h/ralph/umple_configs/bin/cc/logs/Umple/status.txt"/>
</listeners>
<bootstrappers>
<antbootstrapper anthome="/h/ralph/umple_configs/bin/ant" buildfile="/h/ralph/umple_configs/config/bootstrap_umple.xml" target="bootstrap" />
</bootstrappers>
<modificationset quietperiod="30">
<svn localworkingcopy="/h/ralph/umple/trunk"/>
</modificationset>
<schedule interval="300">
<ant anthome="/h/ralph/umple_configs/bin/ant" buildfile="/h/ralph/umple/trunk/build/build.xml" target="build" />
</schedule>
<log>
<merge dir="/h/ralph/umple_configs/bin/cc/logs/umple"/>
<merge dir="/h/ralph/umple/trunk/dist/cruise.umple/qa" />
<merge dir="/h/ralph/umple/trunk/dist/sandbox/qa" />
</log>
<publishers>
<artifactspublisher dest="/h/ralph/umple_configs/bin/cc/artifacts/" dir="/h/ralph/umple/trunk/dist/" />
</publishers>
</project>
</cruisecontrol>
This has two configuration files of interest, the bootstrap (chicken before the egg issue) and the actual build script.
The Bootstrap Build
We created a bootstrap XML file to update the source code so that we get the correct "build.xml" script when building the latest version.
This is available under
/h/ralph/umple_configs/config/bootstrap_umple.xml
This does little more than "update" the source code on the repository so that the remote "build.xml" is the latest and greatest the next upcoming build. I prefer to separate the downloading of the code from the building, as you really want the local builds to behave almost identically to the remote builds.
<project name="UmpleBootstrap" default="bootstrap" basedir="/h/ralph/umple_configs/config" >
<property name="project.dir" value="/h/ralph/umple/" />
<import file="bootstrap_umple.xml" />
<target name="revert">
<echo>Reverting any local modifications</echo>
<exec executable="svn" dir="${project.dir}">
<arg line="revert -R ." />
</exec>
</target>
<target name="bootstrap">
<antcall target="revert" />
<echo>Updating source from Subversion</echo>
<exec executable="svn" dir="${project.dir}">
<arg line="up" />
</exec>
</target>
</project>
The Build
This delegates to a master build.xml file (/h/ralph/umple/trunk/build/build.xml), which is checked in to the code base and should be "runnable" locally.
As we add more projects, more tests, more metrics, etc - this build.xml file will grow and change - but the rest of CC should remain relatively consistent.
The Server
Available at http://cruise.site.uottawa.ca:8080, but currently only the "dashboard" is what we are using.
What is Missing
- Configuring email notifications when things break
- Ensuring test data / reports are available for review. This is partially available, only a somewhat raw and unreadable summary is available