- Define the P4PORT and P4USER Perforce environment variables, so that the CruiseControl configuration can run on multiple machines that might point to different Perforce Servers.
- Utilize plugins to define common behavior.
- Define a single CruiseControl project per Perforce codeline to build.
- Define a single Perforce client workspace per CruiseControl project.
- Name the CruiseControl project and Perforce client workspace so that the project plugin can define a property that maps to its client workspace when instantiated.
- Label builds with the Perforce Changelist Label Incrementer (see below). The Perforce Changelist Label Incrementer allows you to tie a build version directly to the source code versions without having to utilize Perforce labels or a build version to changelist mapping table.
- Create a CruiseControl project of the CruiseControl instance itself so that the instance configuration can be placed under source control. Thus, when changes are made to the CruiseControl configuration through Perforce, the CruiseControl instance is automatically updated.
Perforce Changelist Label Incrementer
By default, CruiseControl generates a label to use for each build; however, because Perforce uses atomic changelists, you can eliminate mapping a build label to source code by using the changelist number as the CruiseControl build label. To do this, use
. For example:
Alternatively, use a plugin for the labelincrementer:
- Using the Perforce changelist label incrementer does not guarantee subsequent build versions increment by 1, as they follow how the changlist numbers increment within Perforce.
- It is possible that a particular codeline's build version corresponds to a changelist that affected a different codeline, but using that number still refers to the correct state of the source code on that codeline. The following is an example scenario of how this can occur:
- A developer submits changelist 1234 to codeline A.
- CruiseControl detects the change and starts to build the project for codeline A, synced to changelist 1234.
- Another developer submits changelist 1235 to codeline B.
- Another developer submits changelist 1236 to codeline A.
- CruiseControl completes building the project for codeline A, whose build version, 1234, also matches the most recent changelist number submitted to that codeline.
- CruiseControl then proceeds to build the project for codeline B. Because changelist 1236 is the most recent changelist, it uses that as the build version and also syncs the codeline B project workspace to that changelist number (which includes changlist 1235).
So while it might seem confusing that codeline B's build version of 1236 does not correspond to a changelist number that affected codeline B, it is completely valid. If a developer wanted to see the source code that corresponded to that build version, they would simply sync their codeline B client workspace to changelist 1236, and see the latest changelist of 1235.