This page last changed on May 20, 2005 by

Rational ClearCase Configuration

Typical / Minimal Configuration

For most uses the following is all you'll need in your ccnet.config :

<sourcecontrol type="clearCase">

This will:

  • monitor ClearCase for any changes on the viewPath or below
  • retrieve the lastest source from ClearCase when any changes are detected
  • apply a label to the built files at the end of the build

The <viewPath> specifies a directory on your filesystem that CCNet monitors for changes. The path must be a versioned object. CCNet checks the actual VOB for changes, not the local filesystem.

<viewPath> doesn't have to be the root of the local ClearCase view. It may be any of the root's children or even a single object.

Full Configuration

<sourcecontrol type="clearCase">

Element Description Type Required Default
viewPath The path that CCNet will check for modifications and use to apply the label. See above for full details. string yes none
branch The name of the branch that CCNet will monitor for modifications. Note that the config spec of the view being built from must also be set up to reference this branch. string no none
autoGetSource Specifies whether the current version of the source should be retrieved from ClearCase bool no false
useLabel Specifies whether a label should be applied when the build is successful. bool no true
useBaseline Specifies whether a baseline should be applied when the build is successful. Requires the VOB your view references to be a UCM VOB. Requires that you specify <viewName> and <projectVobName>. bool no false
executable Specifies the path to the ClearCase command line tool. You should only have to include this element if the tool isn't in your path. By default, the ClearCase client installation puts cleartool in your path. string no cleartool.exe
projectVobName The name of the project VOB that the view path uses. string if <useBaseline> is true none
viewName The name of the view that you're using. string if <useBaseline> is true none
timeout The time, in milliseconds, that CCNet waits for all ClearCase operations to complete. int no 10 minutes

Common Problems

The build is initiated when users check in on private branches

By default, ClearCase returns a history for every file in every branch, even if the config spec limits to a single branch. You must specify <branch> in order to limit which changes CCNet can see.

After the build is successful I get a "Baseline not found" error message.

An example of this message is:

ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed:
cleartool: Error: Baseline not found: "CruiseControl.NETTemporaryBaseline_05-06-2004-16-34-15".

This happens when <projectVobName> is not set to the project VOB. Typically this happens when the user specifies the UCM VOB instead of the project VOB.

To correct the problem, change the value in that element to the name of the project VOB.

Known Bugs

When I view my baselines, I see that they're called CruiseControl.NET[something] instead of v1.0.0.4.

This is a bug in ClearCase; Rational is aware of it. It only occurs if you're using baselines.

CCNet creates a temporary baseline with the prefix CruiseControl.NET before renaming it to the final value, such as v1.5.2.3. Depending on how you view baselines in ClearCase, you may see the temporary or real name.

For example, if you use the admin console, you'll see the old, temporary value. If use use cleartool lsbl, you'll see the correct one:
M:\gsmith_GS_Project_int\GS_UCM_VOB>cleartool lsbl
06-May-04.16:28:27  v1.0.0.1  gsmith   "CruiseControlTemporaryBaseline_05-06-200
  stream: GS_Project_Integration@\GS_PVOB
  component: GS_UCM_VOB@\GS_PVOB
06-May-04.16:34:16  v1.0.0.2  gsmith   "CruiseControl.NETTemporaryBaseline_05-06
  stream: GS_Project_Integration@\GS_PVOB
  component: GS_UCM_VOB@\GS_PVOB

CruiseControl.NET sees checkins on all branches, not just the one specified in my config spec

This is a known issue (CCNET-354) due to the fact that the ClearCase history command (lshist) returns a complete history for the file, not just the history that can be seen by the config spec.

The updates still work correctly so these "phantom" builds contain valid files i.e. not the branched versions that CruiseControl.NET reports on its modification lists.

Document generated by Confluence on Jun 26, 2005 17:22