Cruise now supports linking to a story / bug tracking tool like Mingle from commit messages in Cruise. Use the folloing syntax:

                <pipeline name="cruise">
                    <trackingtool link="http://mingle/projects/cruise/cards/${ID}" regex="#(\d+)"/>
                    ...
                </pipeline>
                

Description: Using the regular expression above, if your commit messages contain messages of the form '#2350', you could see the link wherever you can see the commit message.

After a job has finished on an agent, Cruise can parse any XML files on the agent and set properties on the server. You can use this to harvest metrics like code coverage or cyclomatic complexity from your reports into Cruise, and then export the complete history of your properties from the job detail page to a spreadsheet for custom reporting and analysis. Use the following syntax to tell Cruise the XML files to parse, the XPath to get the property value, and the property name. The following example extracts useful coverage metrics from EMMA reports..

                <job name="test_analysis">
                    <properties>
                        <property name="coverage.class" src="target/emma/coverage.xml" xpath="substring-before(//report/data/all/coverage[starts-with(@type,'class')]/@value, '%')" />
                        <property name="coverage.method" src="target/emma/coverage.xml" xpath="substring-before(//report/data/all/coverage[starts-with(@type,'method')]/@value, '%')" />
                        <property name="coverage.block" src="target/emma/coverage.xml" xpath="substring-before(//report/data/all/coverage[starts-with(@type,'block')]/@value, '%')" />
                        <property name="coverage.line" src="target/emma/coverage.xml" xpath="substring-before(//report/data/all/coverage[starts-with(@type,'line')]/@value, '%')" />
                        </properties>
                        ...
                </job>
                

Description: When you specify this configuration, you can see the properties in the sub-tab 'properties' on job detail page, and export their history to a spreadsheet.

• The performance of CCtray feed is much better than before.
• When the stages or jobs are building, Cruise now supports showing the results of the last build.
• The CCTray feed now supports basic authorization. Specify your username and pssword in the url of cctray feed like this: http://[your-username]:[your-password]@yourcruiseserver:8153/cruise/cctray.xml

Notes: some special characters do not work, e.g. '/'.

Although Cruise has always stored results of re-run stages, you can now access previous runs of a stage easily. We've introducted a 'stage counter' which indexes the runs of the stage.

• The stage history is ordered by time rather than pipeline label in the Stage Activity Page.
• Access any stage details page by the Cruise API http://[your_cruise_server]:8153/cruise/tab/stage/detail/[pipeline_name]/[pipeline_label]/[stage_name]/[stage_counter]

Cruise lets you define multiple repositories in cruise-config.xml if you are using Subversion as you VCS. This means you can easily create pipelines for applications that rely on multiple repositories.

                <pipeline name="cruise">
                    <materials>
                        <svn url="http://xxx.xxx.xxx/trunk" username="yyyy" password="xxx" dest="client">
                        <svn url="http://zzz.zzz.zzz/trunk" username="yyyy" password="xxx" dest="server">
                    </materials>
                </pipeline>
                

You can see material revisions for each pipeline in the sub-tab 'materials' on the job detail page and stage details page, and the tooltips as well. Note that this version of Cruise also treats upstream pipelines as materials, just like source control, which means you can see exactly which version of your upstream pipeline triggered this one (see the screenshot below). Use this syntax to define dependencies between pipelines.

Cruise allows you to specify files in your version control repository that shouldn't trigger a new build when they change (for example requirements documents). You can specify multiple "ignore" blocks with patterns to match, using ant-like syntax:

                <pipeline name="cruise">
                  <materials>
                    <hg url="http://bjcruise.thoughtworks.com/hg/cruise">
                      <filter>
                        <ignore pattern="helper/**/*.*" />
                      </filter>
                    </hg>
                  </materials>
                  ......
                </pipeline>
                

Cruise supports fetching artifacts from previous stage or upstream pipeline in a job by defination of <fetchartifact> in cruise-config.xml. Using this feature it's easy to have one job store artifacts like binaries, jars or installers, and then re-use them in a later stage. This supports best practices like only compiling your application once. Here is an example.

Cruise now supports Perforce. In particular, we support ticket-based authentication.

The support for Git on Cruise is similar to the Mercurial support. Git must be installed on both the server and agents.

• Cruise now allows definition of roles composed of multiple users. You can use these roles anywhere you would restrict access by user (to control administrator access, and to control who can authorise approvals).
• As with 1.0, if security is switched off, Cruise allows all users anonymous read access to Cruise, so that anybody with access to the Cruise server can see the state of builds.

Cruise now allows role-based authorisation for approving a stage manually. This effectively means you can make pipelines 'read-only'. You can specify individually for every stage which group of users or roles are allowed to press the approval button. Specifying roles on the first stage, if it is a manual approval, restricts who can press the "trigger pipeline" button.

Cruise lets you re-run individual stages. Triggering this operation will run the stage with the same source control revisions that it was originally run with. Cruise automatically updates to the original revision it was run with. This is useful if you have a stage that deploys to a testing environment, and you want to re-deploy a historical build to that environment. Hover over a stage on the Pipeline Activity page or click on the re-run button on the Current Activity page. If you re-run a Stage that failed and the Stage passes then the rest of the pipeline will run through as normal.

The Pipeline Activity tab has an improved user interface.

With Cruise 1.1 both the Cruise Server and Cruise Agents are supported on Solaris.

Cruise will display errors on its dashboard if the server has an invalid configuration file, if it cannot contact your revision control repository, or if the revision control client software is not installed on the server. The errors will go away automatically once the cause is resolved.

Cruise now reports Agent actions (such as checking out, or uploading artifacts) in the cruise log that can be viewed through the web page. This makes it much easier to debug issues with source control systems and other Cruise Agent actions.

The agents can be denied from the server through the user interface which means that the Agent will no longer process any work. Click the Approve button to start builds on the Agent again.

Cruise now uses less memory and the web pages are significantly more responsive for very large installations with a lot of history.