Please note that version 1.0 and later of the ClearCase plugin is not configuration-compatible with earlier versions. Projects using base ClearCase will need to be reconfigured, with load rules removed from the config spec and specified separately in the new Load Rules field. This needs to be done for all base ClearCase projects, including those using dynamic views.

With this plugin you can use either base ClearCase and UCM ClearCase as the SCM for Hudson projects. The plugin uses the cleartool executable to work with a ClearCase server - this requires that the cleartool command (and therefore the full ClearCase client) be installed on master and all slaves on which you wish to run ClearCase jobs. The SCM also supports polling, so it can start a build when changes are detected on the branch or stream specified in the job configuration.

Usage

Global configuration

Set up the cleartool executable in the Hudson configuration. To verify that the executable can be used by Hudson press the "Check cleartool version"

Base ClearCase

Basic configuration

Set the name of the view that will be used by ClearCase. The view name has to be unique in the ClearCase region the master/slaves are using.

Set the config spec that should be used. This should not contain any load rules.

Specify one or more load rules - this is required, even with a dynamic view. The load rules are used both for determining the contents of snapshot views and for constructing the "cleartool lshistory" command used for polling and generating changelogs.

Load rules should be separated by newlines.

Load rules should be a path to a file or directory within the view, i.e., "vob/some_vob" or "\some_other_vob\directory". The path can have a leading file separator, or not. You can also have load rules starting with "load", as you would in a snapshot config spec outside of Hudson - the "load " will be removed and the path will be processed as normal.

Check "Use update" if you wish to use the same view for every build - this will greatly speed up your builds, since the view won't be recreated and repopulated every build, but build output will be left in the view.

This option is only applicable to snapshot views. Dynamic views are not removed and recreated.

Specify one or more branches - these branches will be used for polling for changes and assembling changelogs.

Advanced configuration

Click the "Advanced" button to reveal the advanced options, including the dynamic view options.

Excluded regions

Optionally, specify one or more regular expressions representing files or directories which you wish to ignore when polling and generating changelogs. In this example, any changes to a file named "version.properties" or "Version.properties" anywhere in the source tree will be ignored.

Additional mkview arguments

If you need to pass additional arguments to "cleartool mkview", such as -gpath, -hpath, -server, etc, do that here. You can refer to the workspace the view will be under as $WORKSPACE, and the view name as $CLEARCASE_VIEWNAME. These will be replaced before being passed to "cleartool mkview".

Filter destroy sub-branch events

If selected, "destroy sub-branch" events, which are generally the result of removing a version 0 of a file, will be ignored in polling.

Remove ClearCase view on rename

If selected, the view will be removed, via "cleartool rmview", if the job is renamed, since the workspace directory will change and the existing view will no longer be valid.

Multi-site poll buffer

Optionally, if you wish to have polling check for changes since the last build plus an additional period of time, in case of changes made at another site before the build which had not yet been synced to the build site by build time, enter that buffer period here, in minutes.

Dynamic view configuration

Optionally, you can use an existing dynamic view, rather than a new snapshot view. To do so, check "Use dynamic view" under the advanced options.

View root

Required for dynamic view use - this is the directory or drive under which dynamic views live. On Unix, this is generally "/view", while on Windows, it's generally "M:\".

Do Not Reset Config Spec

If selected, the dynamic view's config spec won't be changed, regardless of whether it matches the config spec specified in the job configuration.

UCM ClearCase

To be documented

Frequently asked questions

Are the view attributes available in the build scripts?

There are three environment variables set after checkout :

CLEARCASE_VIEWNAME : The path of the view relative to the workspace

CLEARCASE_VIEWPATH : The absolute path of the view

CLEARCASE_VIEWTAG : The view tag

Can the view name be updated with the name of the job ?

Yes, it is possible to add ${USER_NAME}, ${NODE_NAME} and ${JOB_NAME} in a view name which are replaced with the name of the user, node and job.

Error when creating view (storage directory must be in UNC style)

Jamie Burrell solved it by doing the following at the command line of the machine on which Hudson runs. Note that the view name need not be the one you are using for Hudson. It needn't ever be used. I also had trouble using localhost, and needed to use my machine name.:

The above solution did work but it sets the view storage location globally for everyone in the same region. A better solution may be:
(under the "Advanced" button in the "Additional mkview arguments" field):

-vws \\<host>\<shared folder>\<view name>.vws

Error when retrieving history (Error: Not an object in a vob: "vobs")

On Linux and Solaris there are sometimes problems retrieving the ClearCase history using lshistory. In the Advanced section in the configuration it is possible to specify one or several paths in the VOB path(s) field that will be used when retrieving the history. If the config spec contains "vobs/gtx2" then the VOB path(s) field should be set to gtx2. (Mail thread, issue #1053)

Todo list

Add documentation on how to install a build trigger on a Clear case server

UCM: Add ability to perform difference report between any two builds using baseline

Bug fix : When a view tag exists but the view path has been deleted, the view cannot be created.
Workaround is to execute 'cleartool rmview -force -tag <viewtag>' and relaunch the build

Version 1.3

Released July 13th 2010

Information : This new version stores additional information about the SCM state. As such, when upgrading, a new run of your jobs triggered on SCM polling will be launched in order to record config spec (for Base Clearcase) or foundation baselines (UCM)

New feature : Load rules should be derived from stream foundation - not typed in by user (issue #5898)

RFE: add ClearCase report. Shows ClearCase related information: for builds running with base ClearCase configuration show the the CSPEC that was used. For builds running with UCM ClearCase show the stream and baselines that were used (baselines will be shown only if CodeFreeze option was selected in the UCM ClearCase configuration).

RFE: UCM - Implement code freeze for dynamic view. This includes adding new workflow for UCM checkout: create build stream as a child of the configured stream and use that stream for building.

RFE: UCM - Implement clean build for dynamic view. This is implemented by removing and recreating the view on each build.

Labels:

Anonymous says:

Hi,
I only started using Hudson yesterday, and I love it. Even though my proj...

Hi,
I only started using Hudson yesterday, and I love it. Even though my project isn't using CI, I can, quickly and easily. I have found an omission from your directions though.
We usually use dynamic CC views. That means we don't have a view storage location setup by default. I then had problems with your plugin running and needing a view storage location.
For the edification of others, the error I got was :

I'd completely recommend Hudson and ClearCase. I'm using CC6/Maven2, with a VOB that contains multiple projects, like so:

vobs
+-programme
+-subprogramme
+-project1
+-project2
+- ...

Thanks to Erik's help (the original version I downloaded was missing some required features), I have each of these running as individual builds, with no problems (at least not with ClearCase or Hudson). Bear in mind this is in an Investment Bank on a mission-critical project costing millions of dollars.
Erik is very helpful, highly responsive and the turnaround is pretty high. I can't vouch for the usability of the dynamic views (not having used that side of things), but the rest of it seems top notch.

I have recently tried to use this plugin and it works pretty well for me. ...

I have recently tried to use this plugin and it works pretty well for me. I did notice two issues though:

1. There is no way to supply credentials. If you are using Hudson as a service running under the LocalService account on Windows then it's almost impossible to create a view on a ClearCase server elsewhere on the network. Would it be possible to add support to allow the plugin to impersonate another user whose credentials are authorised to access the server?

2. When I have found that the better option in UCM for Continuous Integration is to make a baseline for each successful and and use diffbl -pred to look for changes. Maybe the SCM plugin could allow the user to either use the lshistory option or diffbl?

then it might be the reason of the Branch has no changes in the given directory (-nco ) and therfore point to (show) the Version of the Parent which mean the Folder will not have the Branch_Type specified by -branch.

You have two options here ... add a Folder to -nco where you are sure you have checkouts and the real Branch Type you looking for ... or even more easy ... check-in & undo-checkout the parent to force a creation of the Branch Type on that folder.

[by the way ... I think the plugin should not FAIL on something like a simple resolve of the history. Maybe the history might not be available but that should not effect the build itself ...]

I am getting this from the "Last UCM ClearCase Polling Log"
I assume it grabs t...

I am getting this from the "Last UCM ClearCase Polling Log"

I assume it grabs the items to look for differences in based on the load rules. I think it's having problems with the newlines in the loadrules, but if I remove the newlines where I enter the loadrules, it gives me another error when trying to get the sources using the update.

Actually, if I run the command on the command line, the error occurs on the -fmt...

Actually, if I run the command on the command line, the error occurs on the -fmt argument. I had to change the single quotes to double quotes and it works on the command line. Is this because the plug-in is mainly for Linux?

This option will be very useful.
In my company users have different access per...

This option will be very useful.
In my company users have different access permission to different folder
When we running ct update and user do not have read access to folder, cleartool return error.
For users with access privilege to secured folder update is fine
Have a nice day.

Hi,
I have just started looking at using Hudson with Clearcase UCM as an altern...

Hi,

I have just started looking at using Hudson with Clearcase UCM as an alternative to CruiseControl and I am finding that things are not working as I might expect them to. The setup menu on Hudson was very straighforward, so I'm assuming that I haven't missed an obvious solution to my issues.

My project has a composite baseline configured with a Read-only component. This component is a Business Information Model which is managed in another project, and releases of this model are made available to various application development projects by including it as a Read-only component. Updates to this Information Model are made available to the development project by changing the Base configuration of the stream, but the changes are not part of the development stream that the Hudson project is configured to look at.

When I change the base configuration, the changes to my read-only component are not picked up on the Hudson server when the view is updated. From what I can see, the plugin re-writes (setcs) the View config spec with the load rules at the start of every build. It then executes an update with an add_loadrules option for each load rule. This kind of update appears to ignore configuration changes on the stream. If a simple clearcase update view, with no additional paramters, is executed then the view configuration is synchronized with the stream, and the modifications to the Read-only component are picked up.

Is there a specific reason why you perform an update for each load rule?

Another potential issue with this approach is that if I remove a component and delete the load rule no update will be execute to remove the redundant elements from the view, where-as setcs followed by a simple update of the view would unload these unncessary elements.

My second issue is that changes to the Read-only component are not detected by the lshistory command because it is only looking at the modifications made to a single stream. In addition to this lshistory on the read-only component would be difficult to work with because the changes to the Read-only component could be made weeks before it is used in the current stream.

A more accurate way of detecting changes might be to parse the update log (which is currently re-directed to NUL) looking for new, updated or unloaded components (ignore Hijacked).

In summary I think there are 2 distinct problems here:

1. Changes to read-only components are not detected and loaded in to the view

2. Changes to read-only components won't trigger a build.

In my case the first problem is the killer because I have to log on to the Hudson server and manually update each affected view when the Read-only component is modified. These changes are generally linked with code changes which will appear in lshistory, so problem 2 would be less important.

Word of caution to folks new to this plugin: open file handles maintained by so...

Word of caution to folks new to this plugin: open file handles maintained by some editors, Windows command consoles, and J2EE apps will prevent the view removal logic from executing properly. You'll see something like this in the build log.

Hi there!
Thanks for creating this plugin.
I have some minor requests for...

Hi there!

Thanks for creating this plugin.

I have some minor requests for it:

1) When using Clearcase snapshot views, a "cleartool lsview" is executed to check if the view already exists, I presume. The problem is that, the output of it should not be shown in the actual job's log, since it's not directly related with the build process.A command like "cleartool lsview $CLEARCASE_VIEWNAME" could be used instead, which would return only the actual view's information, if the view already exists, or return an exit code = 1 if the view doesn't exists, which in this case the view can be created if configured that way.
Really, the main issue for me with this output is that, in large companies, there could be hundreds of views (as in my case) in only one Clearcase region! In which a listing of the full Clearcase Views of that region, not only could take long to get (slowing the build every time), but also will clutter up the build's log, when issue the suggested command, will be faster and cleaner.

2) It would be great to allow variables to be specified in ConfigSpec/Load Rules fields, for greater flexibility. These fields would have to be pre-processed before they were sent/set in Clearcase View. This would allow greater flexibility when creating job's for similar projects that would only have differences in directories names in configspec or load rules.

ex:
1) /vob/customer/project1
2) /vob/customer/project2

- config spec #1 -
element * LABEL1
load /vob/customer/$

Unknown macro: {PROJECT}

- end config spec -

This way we could create a job for a customer that would allow to specify the $PROJECT variable before the build runs, using the parameters feature hudson provides. Like PROJECT=project1 or PROJECT=project2.

3) Alternative of the above, it would be nice to have an extension of this plugin into hudson's parameterized plugin, to allow entering configspec directly when requesting a new build, instead of having to configure the build again, save it, and start the build.

I'm asking this because we use hudson both for continuous integration and official builds. In CI "mode" we use it in a common way. But for official builds, we need to configure the environment, specially the configspec, and this will greatly increase simplicity and flexibility when dealing with a bigger number of jobs.

Could you open a bug at http://issues.hudson-ci.org for #1? The output of lsview...

Could you open a bug at http://issues.hudson-ci.org for #1? The output of lsview showing up in the build log is not deliberate - I'll fix that. You can open feature requests for #2 and #3 as well, though no promises on either of those.

Hello,
Thanks for writing a great plug-in! I appear to be having a permissions...

Hello,

Thanks for writing a great plug-in! I appear to be having a permissions issue that I can't seem to get around. I am unfortunately not too familiar with the cleartool - do I need to provide my login credientials for the Set Config Spec command to work?

I'm having a similar issue. I'm not sure if it is Hudson, ClearCase Plugin...

I'm having a similar issue. I'm not sure if it is Hudson, ClearCase Plugin, or ClearCase itself. I just hung up with IBM and they point the finger back at Hudson.

We have a folder within a VOB that is extra protected. Users of the main group can access the whole VOB, except 1 subfolder. Only users of a special group can access that subfolder. The user that runs Hudson is part of that special group. However, builds from Hudson always come back with Permission Denied.

The interesting thing is, if I go manually onto the Hudson server where the build runs and use ClearCase Explorer to click on the folder within the view, then rerun the job from Hudson, it magically starts working.

One thing I tried is to just run ls or dir on that protected directory from Hudson, and then to also do the same thing from a .bat that the Windows Scheduler runs. Hudson gets permission denied, but the one run by Windows Scheduler works fine. I thought it had to do with Interactive user versus Non-Interactive user. It may still, but using Windows Scheduler worked fine.

Any ideas anyone? Justin, did you figure out a workaround?

Also, I get this problem all the time, including when I start the job and therefore it is started by the right user with access to the special group, not anonymous.

Polling the ClearCase repository now just reports "No changes from last build." ...

Polling the ClearCase repository now just reports "No changes from last build." Even do im sure there are changes on the stream, Is there any one else that have seen this and know why, changes won't be reported or shown on hudson' "Changes site"

Im running a distrubuted setup on 2 machines atm. but we just about to expand to 4, and using "Hudson 1.339" and "Clearcase 1.1.1" and "ClearCase UCM Baseline 1.3" in our configuration.

I just started using Hudson with ClearCase, but it appears that its use of dynam...

I just started using Hudson with ClearCase, but it appears that its use of dynamic views is a bit off when creating new ones for each build. If it finds a view with the same name, it tries to remove it via this odd sequence:

Two problems with this: as you can see, this leaves the view storage laying around, and then the mkview fails as a result. But if you try to manually remove the view storage, it will fail because the view_server process has files open. So to make this sequence work, you would need to do "cleartool endview -server viewname" and then remove the view storage.

Of course, after you've done that, you've effectively rewritten the "rmview" command... so why not just do rmview? I looked in the source and found this line:

launcher.getListener().fatalError("Dynamic view does not support rmview");

I'm not sure what this is about as I have been doing "rmview" on dynamic views for over 15 years, it works fine.

Hi,
It seems that issue with space characters in the load paths have reappeared...

Hi,

It seems that issue with space characters in the load paths have reappeared on the new plugin version. I have older version of the plugin (0.9.1) running on one hudson and latest version 1.2 on other hudson.

The older one specifies load path as

load "/XYZ/ABC File Management.sln"

and newer one specifies the same but in seperate load path section now

/XYZ/ABC Management.sln

The old job succeeds to load the file while the newer one fails saying cleartool: Error: Unable to lookup "ABC" in "\XYZ@@\main\100": No such file or directory.
cleartool: Error: Unable to access "\XYZ\ABC": No such file or directory.
cleartool: Error: Pathname "File" is not a full VOB pathname: it does not begin with a "\".
cleartool: Error: Pathname "Management.sln" is not a full VOB pathname: it does not begin with a "\".

cleartool: Error: 3 config spec load rule problems encountered.
Can you please check if the following fix with plug-in version 1.1 is really fixed?

I've been trying to get Hudson setup to work with ClearCase dynamic views for a ...

I've been trying to get Hudson setup to work with ClearCase dynamic views for a week now with little success. It seems that for some reason Hudson does not have access to the View drives on the machine where I'm running Hudson. I have Hudson installed on a Windows XP machine with ClearCase 7. I setup Hudson to run as a service and run as my user to ensure that it would have access to the same things as myself on this machine. I can also do an "echo %UserName%" from batch scripts executed by Hudson and it will indicate my username. However, it still appears that Hudson does not have permissions to these views.

For example, if I try to change drives to one of my ClearCase view drives in the batch script, I see the following...

C:\hudson\jobs\XXXXXX\workspace>V:
The system cannot find the drive specified.

It also seems that I must put my Hudson workspace directory in the view on the M:\ where I want to execute my build batch script. If I don't, then I will get the following error..

clearaudit: Error: No current view

I also can't put the workspace directory on the drive mapped to the view I'm interested in otherwise I will get the following error.

Started by user anonymous
java.io.IOException: Failed to mkdirs: V:\XXXXXXX
at hudson.FilePath.mkdirs(FilePath.java:812)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1080)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
at hudson.model.Run.run(Run.java:1280)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:137)
Finished: FAILURE

However, it seems that I still only have limited success with using the M:\ view root drive as well. When I do use the view root drive where references to all of my views are located, I still run into problems here where it seems like Hudson has only read-only access for some reason. So I'll see errors like the following...

Whenever I open a DOS command line window (via cmd.exe) and try to run these same batch scripts, they work perfectly. I have access to both the M:\ drive and all of my mapped view drives such as V: that I referenced above. So I don't understand what the difference is between running these batch commands from cmd.exe vs. Hudson running them.

Has anyone had similar problems as this and been able to resolve them?

Hi,
I have install Hudson in my PC with Server Tomcat 7.0 and need download a vi...

Hi,
I have install Hudson in my PC with Server Tomcat 7.0 and need download a view created with
IBM Rational Clear Case, but without need to install Clear Case(without 'cleartool') in this PC.
Does some tool compatible with Hudson exist (open source please)?
The idea that we have is not to index in any external resource the server,
we must have everything necessary in the server without need to install
Clear Case in this one machine and without depending on another machinem
because of it we wanted to know if there exists the
possibility of a free tool compatible with Hudson.
Thanks and Regards

Trying to run a simple batch script that will start my ClearCase build, it fails...

Trying to run a simple batch script that will start my ClearCase build, it fails with "permission denied". When I execute from the command prompt it works. I was able to make this work by setting the Hudson service to start using my login.

hi,
I am newbie at jenkins. I am trying to work with a dynamic ucm view.
But I ...

hi,
I am newbie at jenkins. I am trying to work with a dynamic ucm view.
But I have got "Error: Unabled to change configuration specification: Permission denied" error,
when jenkins set the config spec of view with "cleartool setcs ... " command.
Is there any way of not to reset config spec like base clearcase and avoiding this error.
Thanks in advance..