##### Child pages
• ClearCase Plugin
Go to start of banner

# ClearCase Plugin

Integrates Jenkins with ClearCase.

Plugin Information

This plugin allows you to use either base ClearCase and UCM ClearCase as the SCM for your Jenkins 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.

This plugin doesn't support CCRC (Clearcase Remote Client), and probably never will, given the large differences of implementation between this client and the full client.

The SCM also supports polling, so it can start a build when changes are detected on the branch, label or stream specified in the job configuration.

## Usage

### Global configuration

• Set up the cleartool executable in the Jenkins configuration. To verify that the executable can be used by Jenkins press the "Check cleartool version"
• Choose the default view storage location strategy. This will be applied to all jobs using the plugin. The configuration can be overriden at job level within the advanced section.
• Default : when issuing the mkview command no additional option to specify the view storage is issued. The behaviour will depend on the server configuration.
• Use explicit path : generates -vws argument to the mkview command. The setting specifies a prefix per OS, then the <viewtag>.vws is appended.
• Use server storage location : generates -stgloc argument. You can either use auto or a specific view storage. You'll need to input a label to determine where the command to list storage locations should be issued (since it can vary depending on the host).

### Base ClearCase

#### Basic configuration

• View tag : It has to be unique in the ClearCase region the master/slaves are using. The default value should ensure that, but you can customize it if you know what you are doing. During the build, this value can be referenced using CLEARCASE_VIEWTAG
• View path : the folder where the clearcase view will be created within the workspace. You can use CLEARCASE_VIEWPATH during the build in order to get the absolute path to the view directory.
• You can provide the config spec either inline or by reading it from a file. The file must be reachable from the master node.
• You can provide a command to execute prior to read the config spec in order to refresh it.
• You can then provide either load rules, or choose to read them from the config spec. Load rules are required even for dynamic views, as they are used for polling and also to generate 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 Jenkins - the "load " will be removed and the path will be processed as normal.
• It is possible to poll on different load rules. This allows you to only monitor part of the view.
• 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.
• Specify one or more labels - allows to detect changes by addition or removal of given labels. The plugin will no longer look at checkins, only label addition/removal.

• 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.
• Override view storage : this allows you to override the global strategy (see global configuration above for details)
• 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

#### Basic configuration

• View tag : It has to be unique in the ClearCase region the master/slaves are using. The default value should ensure that, but you can customize it if you know what you are doing. During the build, this value can be referenced using CLEARCASE_VIEWTAG
• View path : the folder where the clearcase view will be created within the workspace. You can use CLEARCASE_VIEWPATH during the build in order to get the absolute path to the view directory.
• Stream selector : the specification for the stream you want to create the view on.
• Define load rules manually : usually load rules can be determined automatically based on the foundation baselines of the given stream selector, but if you wish to use only a part of the load rules defined for the given stream, you will need to specify the load rules to use.
• 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.
• Changeset : this defines what level of details you wish to appear in the resulting changeset. Generating the changeset has a time cost, so depending on what kind of job you run, you may not want everything to appear.
• Build foundation baseline : this option will change the behaviour of the plugin by creating a view not on the stream itself, but rather based on its foundation baseline. When polling, only change of foundation baselines (resulting from rebase operation) will trigger a build.

Most of advanced configuation are common with the Base Clearcase section. With UCM, the following additional options applies :

• Filter Destroy sub branch event : as its name suggests, this will filter out events deleting branches, as this is an operation that is often done through Clearcase hooks.
• Branch name : if specified, the branch name will be used for polling and to build changelogs, rather than extrapolating from the UCM stream name.

#### Dynamic view configuration

Freeze code : This options will create a child stream under the configured stream and will use it for the build. On each build, Jenkins will rebase the build stream with the latest baselines found the configured stream.

## Getting support

• Start by reading the FAQ section below.
• If you don't find what you are looking for, have a look on the jenkinsci-users group.
• Comments on this page aren't monitored regularly, so prefer the user group if you have any question.

#### 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}, ${JOB_NAME} and${DASH_WORKSPACE_NUMBER} in a view name which are replaced with the name of the user, node and job.

We recommend you to use the default view tag, which is jenkins_${USER_NAME}${NODE_NAME}${JOB_NAME}${DASH_WORKSPACE_NUMBER}. This will allow you to generate unique view tag whatever your configuration is.

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

This can happen if no server storage location has been defined for your ClearCase region (this has to be done by ClearCase administrators).

In that case, you can use Override view storage > Use explicit path. The plugin will generate a -vws argument for the cleartool mkview command based on the view tag that you provided and view storage directory that you provided.

#### 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, JENKINS-1053)

## Changelog

1. 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 :

started
[workspace] $cleartool mkview -snapshot <my view name> cleartool: Error: storage directory must be in UNC style (e.g. \\host\share\...) FATAL: Clear Case failed. exit code=1 FATAL: Clear tool did not return the expected exit code. Command line="cleartool mkview -snapshot <my view name>", actual exit code=1 java.io.IOException: Clear tool did not return the expected exit code. Command line="cleartool mkview -snapshot siml_tsa_autobuild_view", actual exit code=1 at hudson.plugins.clearcase.ClearCaseSCM.run(ClearCaseSCM.java:272) at hudson.plugins.clearcase.ClearCaseSCM.createView(ClearCaseSCM.java:175) at hudson.plugins.clearcase.ClearCaseSCM.checkout(ClearCaseSCM.java:108) at hudson.model.AbstractProject.checkout(AbstractProject.java:541) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:223)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:189) at hudson.model.Run.run(Run.java:649) at hudson.model.Build.run(Build.java:102) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:62)  I solved it by doing the following at the command line of the machine on which Hudson runs: cleartool mkstgloc -view mystgloc \\<host>\<shared folder>\<view name>.vws  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. If that is successful, next time you run the build, it should work. 2. Sorry - the above was by me. Forgot I hadn't logged in. Jamie 3. Hello folks, Before bombarding you with questions about ClearCase support, I wanted to ask about the 'readiness' of Hudson for prime time use with ClearCase. Success stories? Cheers, Mike T 4. Mike, 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. Jamie 5. Any plans to add UCM support? I -think- this would boil down to the following additions/changes: - Create views with stream name instead of a specific config spec (config spec is derived from stream configuration); modify UI to take a stream name instead of a config spec - Report contributing activities (UCM tasks) in revision log for builds - Allow builds to be triggered based on changes to latest code, latest baselines, or both (also allow user to specify which components to monitor for changes to streamline these checks) 6. Please use the available mailing lists for requesting features and asking questions about the plugin as this wiki is not being actively monitored. 7. 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? 8. Hi Guys, I got a ClearCase issue like this: [<my view name>]$ cleartool lsactivity -fmt '\"%[headline]p\" \"%[stream]p\" \"%u\" \n' aa_-_bb_cc_dd_ee_ff_gg_hh_ii_jj
FATAL: java.io.IOException: Too many open files


The original log is:

started
[workspace] $cleartool rmview -force <my view name> Removing references from VOB "<my vob path>" ... Removed references to view "<my workspace path>/<my view name>" from VOB "<my vob path>". [workspace]$ cleartool mkview -snapshot -stream <my project name>@<my vob path> -tag <my view name> <my view name>
Selected Server Storage Location "goblin_viewstore".
Created view.
Host-local path: goblin:<my Host-local path>/<my view name>.2.vws
Global path:     <my Host-local path>/<my view name>.2.vws
It has the following rights:
User : <my user name>  : rwx
Group: <my group name> : r-x
Other:                 : r-x
cleartool: Warning: Unable to register new snapshot view: not a ClearCase object
snapshot view may not be recognized by some commands.
Created snapshot view directory "<my view name>".
Attached view to stream "<my project name>".
[workspace] $cleartool update -force -log NUL -add_loadrules <my view name>//<my vob sub path_1> Making dir "<my vob sub path_1>/a". Processing dir "<my vob sub path_1>/a". Making dir "<my vob sub path_1>/a/b". Processing dir "<my vob sub path_1>/a/b". Loading "<my vob sub path_1>/a/b/c" (1842 bytes). Loading "<my vob sub path_1>/a/b/c.inc" (3321 bytes). Making dir "<my vob sub path_1>/a/b/d". Processing dir "<my vob sub path_1>/a/b/d". Loading "<my vob sub path_1>/a/b/d/a.h" (1029 bytes). Loading "<my vob sub path_1>/a/b/d/b.h" (167 bytes). Loading "<my vob sub path_1>/a/b/d/c.h" (206 bytes). Loading "<my vob sub path_1>/a/b/d/d.h" (2540 bytes). End dir "<my vob sub path_1>/a/b/d". ... ... ... ... // Thousands of "Loading ..." here. ... ... Making dir "<my vob sub path_2>/3d/jetty". Processing dir "<my vob sub path_2>/3d/jetty". Loading "<my vob sub path_2>/3d/a/a.tar" (15892480 bytes). Loading "<my vob sub path_2>/3d/a/b.tar" (32051200 bytes). End dir "<my vob sub path_2>/3d/a". End dir "<my vob sub path_2>/3d". Done loading "/<my vob sub path_2>/3d" (5592 objects, copied 1160287 KB). [<my view name>]$ cleartool lshistory -r -since 17-nov.19:25:35 -fmt '\"%Nd\" \"%En\" \"%Vn\" \"%[activity]p\" \"%e\" \"%o\" \n%c\n' -branch brtype:<my project name> -nco <my vob sub path_1> <my vob sub path_2>
"20081117.225225" "<my vob sub path_1>/a/src/com/a/b/c/d/e/f1.java" "/main/<my project name>/2" "a" "create version" "checkin"
"20081117.225152" "<my vob sub path_1>/a/src/com/a/b/c/d/e/f2.java" "/main/<my project name>/2" "a" "create version" "checkin"
Fixes
"20081117.224502" "<my vob sub path_1>/a/src/com/a/b/c/d/e/f3.java" "/main/<my project name>/2" "a" "create version" "checkin"
... ...
... ...  // Hundreds of "history" here.
... ...
[<my view name>] $cleartool lsactivity -fmt '\"%[headline]p\" \"%[stream]p\" \"%u\" \n' a "a" "<my project name>" "tom_matt" [<my view name>]$ cleartool lsactivity -fmt '\"%[headline]p\" \"%[stream]p\" \"%u\" \"%[contrib_acts]p\" \n' deliver.a_11.0.20081117.211100
"deliver a_11.0 on 11/17/2008 9:11:00 PM." "<my project name>" "a" "rebase.a_11.0.20081103.233928 rebase.a_11.0.20081110.005818 a_UTS_00016435_aa_to_bb_cc_dd_dd aa_bb_cc_description"
... ...
... ...  // Thousands of "activity" here.
... ...
[<my view name>] $cleartool lsactivity -fmt '\"%[headline]p\" \"%[stream]p\" \"%u\" \n' aa_-_bb_cc_dd_ee_ff_gg_hh_ii_jj FATAL: java.io.IOException: Too many open files java.io.IOException: java.io.IOException: Too many open files at java.lang.UNIXProcess.<init>(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) at hudson.Proc$LocalProc.<init>(Proc.java:104)
at hudson.Proc$LocalProc.<init>(Proc.java:82) at hudson.Launcher$LocalLauncher.createLocalProc(Launcher.java:311)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:302) at hudson.plugins.clearcase.HudsonClearToolLauncher.run(HudsonClearToolLauncher.java:62) at hudson.plugins.clearcase.ClearToolExec.lsactivity(ClearToolExec.java:67) at hudson.plugins.clearcase.ucm.UcmChangeLogAction.callLsActivity(UcmChangeLogAction.java:142) at hudson.plugins.clearcase.ucm.UcmChangeLogAction.callLsActivity(UcmChangeLogAction.java:158) at hudson.plugins.clearcase.ucm.UcmChangeLogAction.callLsActivity(UcmChangeLogAction.java:158) ... ... ... ... at hudson.plugins.clearcase.ucm.UcmChangeLogAction.callLsActivity(UcmChangeLogAction.java:158) at hudson.plugins.clearcase.ucm.UcmChangeLogAction.callLsActivity(UcmChangeLogAction.java:158) at hudson.plugins.clearcase.ucm.UcmChangeLogAction.parseHistory(UcmChangeLogAction.java:106) at hudson.plugins.clearcase.ucm.UcmChangeLogAction.getChanges(UcmChangeLogAction.java:56) at hudson.plugins.clearcase.AbstractClearCaseScm.checkout(AbstractClearCaseScm.java:205) at hudson.model.AbstractProject.checkout(AbstractProject.java:664) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:260)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:234) at hudson.model.Run.run(Run.java:793) at hudson.model.Build.run(Build.java:88) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:88)  I think it probably because I have too many history and activity, Hudson could not handle it. Could I just disable the "Changes Analysis" in Hudson, how to do it? Thanks for your help! 9. Dear all, [...] [Qestion move. cf Mailing list] -- ALU 10. I try to use Clearcase-Plugin with Snapshot-Views. My config-spec has a large size, so it's impüossible to use, because i got an error. A good solution for this would be a checkbox "Use existing view" which doesnt need a config-spec. On the other hand i tried also a Dynamic-View where i got an error "cleartool -lshistory ...." getting filesize too large. Any ideas on this or do you need a detailed error description ??? 11. If you have an UCM View Branch Setup like: VOBs +-Features +-Integration +-Project +-ProjectBranch1 +-ProjectBranch2 +- ...  with e.g. a Folder structure in the Project like: \Root \src \generated \libs ...  and ever come accross the following error on Hudson: []$ cleartool lshistory -r -since 7-mar.21:31:29 -fmt '\"%Nd\" \"%En\" \"%Vn\" \"%[activity]p\" \"%e\" \"%o\" \n%c\n' -branch brtype: -nco Root
FATAL: UCM ClearCase failed. exit code=1
FATAL: cleartool did not return the expected exit code. Command line="lshistory -r -since 7-mar.21:31:29 -fmt \"%Nd\" \"%En\" \"%Vn\" \"%[activity]p\" \"%e\" \"%o\" \n%c\n -branch brtype: -nco Root", actual exit code=1
java.io.IOException: cleartool did not return the expected exit code. Command line="lshistory -r -since 7-mar.21:31:29 -fmt \"%Nd\" \"%En\" \"%Vn\" \"%[activity]p\" \"%e\" \"%o\" \n%c\n -branch brtype: -nco Root", actual exit code=1
at hudson.plugins.clearcase.HudsonClearToolLauncher.run(HudsonClearToolLauncher.java:76)
at hudson.plugins.clearcase.ClearToolExec.lshistory(ClearToolExec.java:57)
at hudson.plugins.clearcase.ucm.UcmChangeLogAction.getChanges(UcmChangeLogAction.java:61)
...


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

12. Hi,

My requirement is to apply labels on source code before build and update the snapshot view using the latest label. The label will be based on build number ex:1.1.buildnumber.1

1.Apply label on all the source files ex:1.1.buildnumber.1.

I can use NAnt for this.

2.Update the view.

Is it possible to use Hudson variables in config spec.

element * CHECKEDOUT
element 1.1.$Unknown macro: {BUILD_NUMBER} .1 element * /main/LATEST it seems this does not work. Any other work-around for this. 13. 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. Started on Apr 6, 2009 3:45:42 PM TTC_svccadm_view$ cleartool lshistory -r -since 6-apr.14:57:45 -fmt '\"%Nd\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n' -branch brtype:TTC1_Int -nco ttc_boot
ttc_focus
ttc_primitives
ttc_ecos
ttc_tools
cleartool: Error: Unable to access "ttc_boot
": Filename too long.
cleartool: Error: Unable to access "ttc_focus
": Filename too long.
cleartool: Error: Unable to access "ttc_primitives
": Filename too long.
cleartool: Error: Unable to access "ttc_ecos
": Filename too long.
Done. Took 0.59 sec
No changes

Is there anything I need to do to set this up better?

1. 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?

14. Hello
I would like to get source in Clear Case with polling mode using Hudson.

But I can not find how to ignore cleartool error during update snapshut view.

※ We can do like following lines in Ant.

<ccupdate viewpath="$Unknown macro: {ViewPath} " graphical="false" overwrite="true" rename="false" failonerr="false" /> ※ Hudson always use following option to update view "c:\Program Files\Rational\ClearCase\bin\cleartool.exe" update -force -log NUL hudson_frontier_view Do you know how do I ignore cleartool error without using Ant? I wonder if Hudson use polling mode when Hudson invoke Ant file to update clear case view or not. Have a good day. 1. Hi - We don't have the option of ignoring errors in cleartool executions, nor do we intend to add that option. Sorry. A. 1. 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. 15. 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. Has anyone else encountered these issues? regards Duncan 16. 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.  Removing references from VOB "\MY_PVOB" ... Removed references to view "E:\hudson\jobs\job_name\workspace\view_name" from VOB "\MY_PVOB". cleartool: Error: E:\hudson\jobs\job_name\workspace\view_name\view_root_dir\path\to\some\file.extension: Permission denied ... cleartool: Error: Unable to remove the snapshot view directory. cleartool: Error: E:\hudson\jobs\job_name\workspace\view_name: Directory not empty cleartool: Error: Unable to remove the snapshot view directory. at hudson.plugins.clearcase.ClearToolSnapshot.rmview(ClearToolSnapshot.java:144) at hudson.plugins.clearcase.action.UcmSnapshotCheckoutAction.checkout(UcmSnapshotCheckoutAction.java:87) at hudson.plugins.clearcase.AbstractClearCaseScm.checkout(AbstractClearCaseScm.java:410) at hudson.model.AbstractProject.checkout(AbstractProject.java:1003) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:428)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:376) at hudson.model.Run.run(Run.java:1174) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:123)  The remedy appears to be to restore the plugin's desired end state--a snapshot view with the correct owner and name. To achieve this, I 1. login as the same user that runs the hudson service, 2. remove the offending directory after closing all programs that might have handles open, then 3. create the view using the command from a successful build's log, 4. update the view from windows explorer (could be done from commandline also), and 5. manually kick off the job. If anyone else has run into similar problems and found a better way of recovering, I'd love to hear about it. 17. Hi, Does anyone know if this plugin supports CC 7.1? Thanks, Roshan 18. 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.

Thanks!

1. Could you open a bug at http://issues.jenkins-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.

19. Hi,

I have started using Hudson and integrated CC plugin. I am getting the following error while trying to run the build.
I need to know how to set a CC view through hudson?

Console Output:
Started by user anonymous
sbarathu_lat $/usr/atria/bin/cleartool pwv -root /view/sbarathu_lat workspace$ /usr/atria/bin/cleartool startview sbarathu_lat
workspace $/usr/atria/bin/cleartool catcs -tag sbarathu_lat element * CHECKEDOUT #element /cm4/tools/coverity/... /main/LATEST element /vobs/esam/configspecs/ISAM_mainstream.cs /main/aaaa/isr41/51 include /view/LATEST/vobs/esam/configspecs/ISAM_mainstream.cs@@/main/aaaa/isr41/51 sbarathu_lat$ /usr/atria/bin/cleartool lshistory -all -since 1-feb-10.12:38:41utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -nco vobs/esam/configspecs vobs/esam/build
workspace $/bin/sh -xe /var/tmp/hudson4754014555775014105.sh + /usr/atria/bin/clearmake -C gnu -f /vobs/esam/build/ecnt-c/OS/Makefile E=SUN VERBOSE=X all clearmake: Error: Unable to open file "/vobs/esam/build/ecnt-c/OS/Makefile": No such file or directory. Finished: FAILURE 20. 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? workspace$ cleartool rmview -force hudson_view_auto
workspace $cleartool mkview -snapshot -tag hudson_view_auto -vws \\Fm5sgcedevs04\workspace\hudson_view_auto\view.stg.vws hudson_view_auto Created view. Host-local path: Fm5sgcedevs04:C:\Program Files\Hudson\jobs\Test Build 001\workspace\hudson_view_auto\view.stg.vws Global path: \\Fm5sgcedevs04\workspace\hudson_view_auto\view.stg.vws Created snapshot view directory "hudson_view_auto". hudson_view_auto$ cleartool setcs ..\configspec62998.txt
cleartool: Error: Unable to access "\gfx_Development\Test\Tools": Permission denied.
cleartool: Error: Unable to access "\gfx_Development\Test\ghal3d": Permission denied.
cleartool: Error: Unable to access "\gfx_Development\Tools": Permission denied.
cleartool: Error: Unable to access "\gfx_Development\Source": Permission denied.
cleartool: Error: 4 config spec load rule problems encountered.

Thanks,

-Justin

1. I think the problem is that access is controlled to our clear case server, yet hudson is accessing as anonymous.

Started by user anonymous

-Justin

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

1. I had to modify the Hudson service to run as a user with permissions to access ClearCase. I currently am pre-creating the view manually before kicking off the Hudson job.

I don't think I have seen your particular permissions problem though.

-Justin

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

Thanx

btw. im using ClearCase LT version 6.15 AND UCM

THE ERROR WE ARE GETTING IS AS FOLLOWING:
Started on 09-03-2010 13:02:26
workspace $cleartool pwv -root C:\path\to\workspace workspace$ cleartool lshistory -all -since 9-mar-10.10:02:25utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \"%activityp\" \n%c\n' -branch brtype:branchname -nco '"265_Rc\Rc_ProdSw "' '"265_Rc\Rc_SubSys "' '"265_Rc\Rc_HwTest "' '"265_Rc\Rc_Lib "' '"265_Rc\Rc_Hal "' '"265_Rc\Rc_Tp "' '"265_Rc\Rc_Model "' '"265_Rc\Rc_Func "' '"265_Rc\Rc_WinSim "' '"265_Rc\Rc_Safety "' '"265_Rc\Rc_Ui "' '"265_Rc\Rc_Si "' 265_Pump\P_RcpcPumpSi
"20100309.123316" "USER" "C:\path\to\workspace\VOB\COMPONENT\paht\to\chnages\file" "\main\MS_E_mainline_int\branchname\3" "create version" "checkin" "Activity identifier"

Done. Took 1,2 sec
No changes

why does it say "No changes" when there are a change????....

22. 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:

workspace $/usr/atria/bin/cleartool rmview -force -avobs -uuid d8b2ef8f.4e5411df.91cb.00:1d:09:70:2e:5e workspace$ /usr/atria/bin/cleartool unregister -view -uuid d8b2ef8f.4e5411df.91cb.00:1d:09:70:2e:5e
workspace $/usr/atria/bin/cleartool rmtag -view hudson_view workspace$ /usr/atria/bin/cleartool mkview -tag hudson_view -host sdc60010vob -gpath /net/sdc1006nap.us.oracle.com/vol/sdc60010vob/vws/hudson_view.vws -hpath /ccase/vws/hudson_view.vws /ccase/vws/hudson_view.vws
cleartool: Warning: "/ccase/vws/hudson_view.vws" and "/net/sdc1006nap.us.oracle.com/vol/sdc60010vob/vws/hudson_view.vws" do not reference the same filesystem location.
cleartool: Warning: Storage pathname "/ccase/vws" may not reside on host "sdc60010vob".
cleartool: Error: Unable to create directory "/ccase/vws/hudson_view.vws": File exists.
cleartool: Error: Unable to create view "/ccase/vws/hudson_view.vws".
FATAL: Base ClearCase failed. exit code=1

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.

++thanks,
trent...

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

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?

Bug fix: Load rules containing spaces are now handled properly in cleartool calls. (issue #4443)

Regards,

abhijit

24. if specify "branches" , hudson use cleartool lshistory -r -since 23-jun-10.08:29:40utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:FDT1105 -nco

to get update.

We may have "/main/b1/FDT1105" & "/main/b2/FDT1105"

Is there any way to select specific branch, just add "grep /main/b1/FDT1105" when lsh ?

25. I want to modify the current clearcase plugin to meet the demand of our project. Can anybody tell me how to copy the clearcase plugin source codes without copying it manually from Fisheye repository.

Regards,
Aswini

26. Hello ,

I am using Hudson and ClearCase pluggin, but I have some problems, I'm running on REDHAT OS

I declared a node slave and i want to execute a shell with the command  cleartool setview <view_name> and it's works, but when I run cleartool pwv it shows me that there is no view set.

May someone help me with this issue ? Has anyone a idea ?

I'm using a dynamic view, which already exist.

Regards,

Ciprian

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

WARNING XXXXXX: Could not create temp dir in M:/xxxxxx_view7: couldn't create directory "M:\xxxxxx_view7\xxxxx_tmp_3840_0": The media is write protected (error code 19)

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?

28. Hi,

Sorry, if this was already posted...

I'm running hudson on linux with a hudson-slave on a windows server using clearcase plugin(1.3.3)

To get around the permission issue below...you'll need to change the user id the hudson-slave service is running as.  It's currently running as SYSTEM which is why i was getting the error below.

cleartool: Warning: Config spec OK, but unable to tell view server to load.
cleartool: Warning: View server should be restarted.
cleartool: Error: Unable to change configuration specification: Permission denied.
FATAL: UCM ClearCase failed. exit code=1

Hope this helps...

1. PLEASE DO NOT DO THIS, IT CRASHED MY SERVER!!!...Sorry if anyone has tried it already.  it's fine after running the cleartool setcs, but when it runs maven commands, it's downhill after that...

29. The plugin does not detect a change even though when I run the same command in ClearTool I see the change!

Is it something with the single quotes around the -fmt string?

Thanks,
Mark

30. Hi there, I'm having problems specifying Excluded Regions with this plugin.  I am not sure if the search space includes the workspace directory or not.

I have tried both (where the first specifies the workspace, and the second doesn't):

machine_master_project_hudson/src/public/.*

src/public/.*

Neither of these works - polling still picks up changes within the /public directory.  Can anyone please tell me what I might be overlooking?

I'd like it to poll for changes on a baseline, but it seems like plugin wants to look at a branch.. Can I turn this off?

1. hey

you should look at this plugin also ClearCase UCM Plugin it might be exactly what you are looking for

1. It's so close.. but I really want dynamic views..

32. Hey

Is there any way to hide the clearcase update log from the build log? WIth so many files in our views it makes the logs unnessarily large. Our main focus is the build log, not so much the update log.

ie.

End dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2003".
.
Processing dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005".
.
Processing dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005\libspeex".
..
End dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005\libspeex".
.
Processing dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005\speexdec".
..
End dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005\speexdec".
.
Processing dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005\speexenc".
..
End dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005\speexenc".
.
End dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\VS2005".
..
Processing dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\libspeex".
.....
End dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\libspeex".
..
Processing dir "1062_GEN3\target_hmi\src\3rdParty\pjsip\third_party\speex\win32\speexdec".
...Cheers
Cheers

33. I still only see version 1.3.7 available in Jenkins.

34. Please notice you have a typo in "upgrade guide to 1.3.7" groovy script for unixStorageDir

It should be:

unixStorageDir = jenkins.getDescriptor(ClearCaseSCM.class).defaultUnixDynStorageDir

35. I'm currently replacing tokens in a configspec before calling the job with clearcase SCM. My problem now is that I need to set in the LABELs section a variable that should point to the tokens values previously set.

The question is: Why isn't the LABELs section accepting variables?! That is not very flexible... :(