• Create, manage, and use an environment
• Associate agents with an environment

• Ensure only one instance of a pipeline can run at the same time
• Set variables on an environment
• Set variables on a Job
• Run a job on all agents that match environment and resources
• Schedule pipelines based on a timer (e.g. for nightly builds).
• Default to kill any running tasks when a stage is canceled
• Pipeline templates help to remove duplication in the config file
• Deploy specific revisions of materials to an environment

• Agent API - Enable and disable an agent
• Scheduling a pipeline with specific material revisions
• Releasing a pipeline lock

• Bulk edit of agent resources
• Bulk enable and disable agents

• Go now recognizes when you use the same source control repository in multiple pipelines, and only polls it once per minute, regardless of how many times it's referenced.
• In previous versions Go would not poll repositories in a manual pipeline. Go will now poll all repositories by default. You can prevent automatic updating of a material by setting autoUpdate="false" on the material.

• CRUISE_XXX variables are deprecated since Go 2.0. Please use GO_XXX instead of CRUISE_XXX (For example: GO_SERVER_URL instead of CRUISE_SERVER_URL).

Go now supports linking to a story / bug tracking tool like Mingle from commit messages in Go. 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, Go 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 Go, 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 Go 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, Go 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 Go has always stored results of re-run stages, you can now access previous runs of a stage easily. We've introduced a 'stage counter' which indexes the runs of the stage.

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

Go 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="main">
    <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 Go 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.

Go 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>
    

Go 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.

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

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

• Go 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, Go allows all users anonymous read access to Go, so that anybody with access to the Go server can see the state of builds.

Go 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.

Go 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. Go 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 server and agents are supported on Solaris.

Go 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.

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

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

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