The About page describes the Cruise version and the environment the Cruise Server is running on.

You cannot run multiple agents on the same box as of now.

Common reasons for Cruise not running include:

Not enough memory - Cruise needs at least 1GB RAM for the Cruise Server or 128M for the agent. The default value of MAX Memory is 1024m. You can change it in the file named 'wrapper-server.conf' at ${Installed Server}/config.Occupied port - The ports that the agent connects with the Cruise Server are 8153 (http for agent bootstrapper) and 8154 (https for agent). You can change them in server.cmd and agent.cmd (for window) or server.sh and agent.sh (for Linux and Max) to resolve the port issue. Or you can make sure the port is freed

Common reasons are:

Bad networkIncorrect URLUsername and password are required but not provided or not correctCruise needs to have the correct version of Source Repository client installed. Please check the configuration reference to check what versions are supported.

When Cruise fails to connect, it shows an error that includes the commandline that is being used. You can test this by copying and pasting into a command prompt to check that the command works correctly.

You don't need to have your build script do an update in Cruise - in fact, it's a bad idea to do so. Imagine - Cruise detects a modification and schedules a build. Between the build being scheduled and actually building, somebody checks in a new change. Cruise then begins building, having updated its working copy to the same version that triggered the build. Your script however then proceeds to update to HEAD, and builds a different version of the source control. If the new change introduces a bug, the build will fail- but when you go to find out why, Cruise will tell you the version that it thought it was building, not the version it was actually building.

Say, you use Mercurial (hg) for your source control and an error happened during 'hg pull' for the first build, you have to do 'hg clone' manually first to handle this. Again, the solution is not to do an update from your build. Although you had to do this with the early versions of open source CruiseControl, it is no longer necessary. In fact, it is harmful due to the race condition above.

If you cancel a Job, Cruise currently just ignores the response from the agent, but the agent will still run the Job until it finishes. This is because it is non-trivial to stop running processes in most cases since many builds create child processes. This is being considered for a future release.

The most likely cause is contention for resources. For example, consider the following situation:

There are two jobs, one which requires a resource 'lots of memory', one without.

When both the Jobs are scheduled, it may be that the Job which requires no resources gets assigned first, and is assigned to the agent with the resource 'lots of memory'. In this case, the Job which requires the resource 'lots of memory' will have to wait until the first Job finishes. In addition, since one agent can only run one Job at any time, the execution becomes sequential.

If the server is running when you add Stages or Jobs, you can see them once they are scheduled to build.

This is a known limitation of the system. Since the stage order has changed, and is ambiguous, Cruise ignores the manual approval. You can still approve on newer pipelines.

Currently Cruise loads the cruise-config.xml, ignoring the comments when it starts. Once you change the configuration through UI, Cruise rewrites the file losing the comments on the way.

For agents on Linux

stop the agent using '/etc/init.d/cruise-agent stop'change the server ipaddress in the file '/etc/default/cruise-agent'delete all file with the extension name .jks in the folder '/var/lib/cruise-agent/config'delete the file guid.txt in the folder '/var/lib/cruise-agent/config'restart the agent using '/etc/init.d/cruise-agent start'

For agents on Windows

stop the agent servicechange the environment variable named 'Cruise-server' to the new server ipaddressdelete all file with the extension name .jks in the folder '${installed agent folder}/config'delete the file guid.txt in the folder '${installed agent folder}/config'restart the agent service

Currently, Cruise only supports Junit and Nunit. The format of your test results should be XML. The result must be sent back to the server using <test src='${the folder of your test results}'/> in the Job definition.

Make sure that Cruise has permissions to create a directory for artifact repository and can write files into it. On linux, you can manually create an 'artifactdir' and change its owner to cruise:cruise.

You can build java 1.5 projects with Java 1.6. In fact this is the recommended way to do it. Most IDEs already do this.

The way to do it is to set the source and target properties on your ant javac task (see : http://ant.apache.org/manual/CoreTasks/javac.html )

Copied from there:

source -- Value of the -source command-line switch; will be ignored by all implementations prior to javac1.4 (or modern when Ant is not running in a 1.3 VM) and jikes. If you use this attribute together with jikes, you must make sure that your version of jikes supports the -source switch. By default, no -source argument will be used at all. Note that the default value depends on the JVM that is running Ant. We highly recommend to always specify this attribute. A default value for this attribute can be provided using the magic ant.build.javac.source property.

target -- Generate class files for specific VM version (e.g., 1.1 or 1.2). Note that the default value depends on the JVM that is running Ant. In particular, if you use JDK 1.4+ the generated classes will not be usable for a 1.1 Java VM unless you explicitly set this attribute to the value 1.1 (which is the default value for JDK 1.1 to 1.3). We highly recommend to always specify this attribute. A default value for this attribute can be provided using the magic ant.build.javac.target property.

MacOSX applications do not see environment variables that are defined in the usual unix places. You have to add them to an environment.plist file.

See this article for more information: How to define environment variables so that MacOS X applications can see them

This is caused by a missing dependency during installation. Cruise uses the unzip command during installation and if this command is not available then the install will fail and the server will not be able to start.

To validate that this is your issue, try running the unzip command. If ubuntu reports that it is not installed, this is your problem.

$ unzip The program 'unzip' is currently not installed. You can install it by typing: sudo apt-get install unzip -bash: unzip: command not found

To fix this issue:

Remove (purge) partly installed Cruise by running :

sudo dpkg -P cruise-server

Install unzip:

sudo apt-get install unzip

Re-install Cruise:

sudo dpkg -i cruise-server-XXXX.deb

After you re-run a stage, you can see the previous run of the stage on the 'Stage Activity' Page. All the stage runs will show up in the order of the timestamp.

You can add the element <filter> under each material. See the details.

Since R1.2, you can define multiple materials with a destination folder. However this is supported only for Subversion at present. See the configuration reference.

Currently Cruise does not support any other locales. For instance, if you set LANG=zh_CN.UTF-8 in linux, cruise won't work properly.

We support msysgit 1.6. You also need to add ${installed-path}/cmd and ${installed-path}/bin into environment variable $PATH, then restart the Cruise Server.

If the pipeline uses ssh protocol, it will not be triggered when password is required. This is known issue of msysgit, see http://groups.google.com/group/msysgit/browse_thread/thread/3e75fdb1b133d858/976c3487d8f88da5

If there are some special characters in your password, you have to XML escape them. For example,

You can customize the utilization of memory by adding 'SERVER_MAX_MEM=2048m' into file either /usr/share/cruise-server/server.sh on linux or server.cmd on windows. That means Cruise server will use 2G memory when it starts.

Cruise agents always compress the artifacts, irrespective of a file or a folder, using ZIP before they transfer them to the server. The server then uncompresses the zip files to the location defined in cruise-config.xml. Cruise uses the system temporary directory to perform the compression/decompression.

As of now, Cruise can reliably upload artifacts that are 1GB or lesser in size. So, if the artifact is bigger than this, the task may fail. Also, make sure there is enough disk space on both Agent and Server. This process is slower on Windows than on linux.

This is a known issue. When the agent is a local agent or there are more than one Network Adapter on the agent, Cruise may ask you to re-approve it. You will have to remove the agent from cruise-config.xml using the administration screen. Then Cruise will see the Agent as a new Agent and ask you to approve it.