What's new in Cruise
Cruise 1.3
New features
- User tab to manage email notifications, with the ability to match check-ins to users
- Run multiple Cruise agents on one machine
- Cancelling a stage can run a process to clean up on the agent
- Conditional task execution for jobs
- Support for Git branches and submodules
- Cruise server warns you when its disk space is running low
- Set environment variables containing the source control revision id when running a task
- We now support SUSE [server|agent] (tested on Linux Enterprise Server 10 SP2).
- We now support Solaris [server|agent] (tested on SunOS Solaris10 5.10).
In the professional edition:
- Ability to group (and secure) similar pipelines
- Pipeline dependencies
- Lock down who can view and operate pipelines
- More than one material per pipeline
Changes
- Changes with multiple materials highlights what has actually changed since the previous revision. If you used multiple materials (e.g. more than one source control) in the same pipeline, Cruise shows the latest revision for each of the materials, even if that is the same as the previous pipeline instance. Cruise now highlights the changes since the previous pipeline instance.
- You can now define groups of pipelines. This makes it easier to configure and define security on pipelines based on logical grouping for your organization. See change permissions for different actions for more information.
- Cruise server can now be downloaded as a single jar. For more information see running Cruise without an install.
- The "Pipelines" tab has been removed. The Pipeline Activity page provides a much better visualizatiion.
- Manual pipelines no longer poll source control. A pipeline with a manual first stage will not check source control until it is manually triggered. This helps reduce the number of requests to source control systems.
- Artifacts to be uploaded can now be specified with wildcards. For more information see uploading test reports.
- Artifacts are now stored on the server in directories named for the pipelines. The directory for a pipeline is "pipelineName/pipelineLabel/stageName/stageCounter/jobName". Artifacts already created will still be accessible in the existing directories, but new pipelines will use the new directory layout, This was done since some operating systems restrict the number of directory entries which can cause errors when building many pipelines.
- Cruise will now obscure show source control passwords. Cruise will show passwords as "******" in the UI and in logs. Note that only the logs created by Cruise itself are obscured. If a tool or script prints out a password then it may appear in the logs.
- Forcing a pipeline will create a new pipeline instance even if there are no changes in the materials. In Cruise 1.2 forcing a pipeline would re-run the existing pipeline if there were no changes in the materials. After feedback from our users we have removed this change. If you do want to re-run an existing pipeline instance you can still do so, by clicking the re-run button on the first stage of that pipeline.
- Licensing has been changed. You will need a new license if you have a paid version. Please go here to see details.
Cruise 1.2.1
Changes
- Fixed the issue of full-checkout on agent side for Perforce.
- Fixed the issue of full-checkout on agent side for when the option of 'checkexternals' is on.
- Manually triggering a pipeline will generate a new pipeline instance even though there is no modification detected. Also it will update to most recent revision, including filtered files.
Cruise 1.2
New features
Cruise 1.2 offers many new features and enhancements in terms of usability and performance.
Support tracking tools to integrate with other management tools.
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.
Set properties from artifact using XPath automatically.
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.
Improved CCTray feed
- 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. '/'.
Support to access re-run stages.
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]
Support multiple repositories for Subversion
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.
Ability to filter materials
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.
The pattern takes the root directory of the SCM repository as the root directory, not the sandbox in the agent side or the materials URL.For example, the structrure of a subversion repository is following:
The material and changes look like
If we want to ignore files under /trunk/lib/tmp, the configuration is:
<svn url="http://10.18.3.171:8080/svn/connect4/trunk/lib" username="cce" password="cru1s3" dest="lib">
<filter>
<ignore pattern="trunk/lib/tmp/**/*.*" />
</filter>
</svn>
Fetching artifacts
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.
Changes
- Refactored Cruise API and remove some calls. See the Cruise API topic for more details.
- Treate the dependency of pipelines as the materials of the pipelines. This means you can see which version of your upstream pipeline triggered the current pipeline anywhere on the UI you see modifications. Your configuration will be upgraded automatically.
- Limit the number of materials of pipelines. Cruise Free Edition supports only one material, and Enterprise Edition support unlimited materials. The other versions support three materials.
- Cruise agent no longer bundles Ant as of version 1.2.
- Clean the folders which is not under any 'dest' folders of all mateirial on agents.
Cruise 1.1
New features
Cruise 1.1 offers many new features and enhancements in terms of usability and performance.
Support for Perforce
Cruise now supports Perforce. In particular, we support ticket-based authentication.
Support for Git
The support for Git on Cruise is similar to the Mercurial support. Git must be installed on both the server and agents.
Role-based security
- 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 authorize 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.
Authorization for approvals
Cruise now allows role-based authorization 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.
Re-run a stage
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.
UI improvements for pipeline activity
The Pipeline Activity tab has an improved user interface.
Solaris support
With Cruise 1.1 both the Cruise server and Cruise agents are supported on Solaris.
Better server error reporting
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.
Better console out information
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.
De-authorize agents through UI
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.
Improved performance
Cruise now uses less memory and the web pages are significantly more responsive for very large installations with a lot of history.
Changes
- Cruise no longer bundles SVN - the server and all agents need to have Subversion installed and available in the system path
- Approvals are now at the start of a stage not the end of the stage. This means that it is possible to add a pipeline that will only be run if you manually trigger it (in other words, revision control changes will not automatically trigger it). To do this, add a manual approval to the start of the first stage.