ClearCase Plugin

Integrates Hudson with ClearCase.

Plugin Information

Plugin ID clearcase
Latest Release 1.1.1
Latest Release Date Jan 16, 2010
Changes via Fisheye In Latest Release
Since Latest Release
Maintainer(s) Andrew Bayer (id: abayer)
Issue Tracking Open Issues
1.0 and Later Configuration Incompatible With Earlier Versions

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

Is the view name available in the build scripts?

Yes, the view name can be accessed through the environment variable CLEARCASE_VIEWNAME, which contains the name of the view. The environment variable CLEARCASE_VIEWPATH contains the absolute path to the view folder.

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

Yes, from version 0.6 it is possible to add ${USER_NAME} and ${JOB_NAME} in a view name which are replaced with the name of the user 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.:

cleartool mkstgloc -view mystgloc \\<host>\<shared folder>\<view name>.vws

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

Roadmap

Next major release in developmment

  • Tentative: Planning to move UCM Make Baseline functionality out of main ClearCase plugin and into new "ClearCase Tag" plugin, along with new label functionality.

Changelog

Version 1.1.2

  • In trunk
  • Bug fix: If load rules ended with slash or backslash, no checkins would ever be registered as valid changes. (issue #5342)
  • Bug fix: Handle variable replacement in view name properly during job deletion or renaming. (issue #5364)

Version 1.1.1

  • Released Jan 16 2010
  • Bug fix: Adding -overwrite to setcs call broke with ClearCase 6 - setcs there didn't yet support -overwrite. Removed -overwrite. (issue #5212)
  • Bug fix: Variable replacement depending on Computer in view name now works properly during polling. (issue #5214)
  • Bug fix: Add support for computer environment variables being used in view name macros. (issue #5222)
  • Bug fix: NPE when using existing UCM jobs without override branch name specified - now we check for null, just to be safe. (issue #5238)
  • Bug fix: Made normalizedViewName thread-local in order to support node name resolution in matrix configurations properly. (issue #2934)
  • Bug fix: UCM updates now use the -overwrite option. (issue #4775, issue #3588)
  • Bug fix: Dynamic view setcs calls now made from view root, not workspace root. (issue #5243)
  • Bug fix: Fixed dynamic view getModuleRoot having extra slash in cross-platform master/slave use cases. (issue #4526)

Version 1.1

  • Released Jan 5 2010
  • Bug fix: Load rules containing spaces are now handled properly in cleartool calls. (issue #4443)
  • Bug fix: Use cases where the slave is run in a setview shell (so that the dynamic view is already started and source is accessed directly through, say, "/vobs/foo") are handled properly for polling and determining changelogs.
  • RFE: Changing from using "cleartool update" to "cleartool setcs -current" for base snapshot views (and calling "cleartool setcs -current" for base dynamic views without changes in the config spec) to handle included config specs, etc. (issue #4569)
  • RFE: Added optional, advanced option for UCM jobs for branch name - by default, stream is used, but if the override branch name is specified, it will be used for polling/changelog instead. (issue #4575)
  • Bug fix: Discovered that views were still not being properly deregistered when processWorkspaceBeforeDeletion gets called - changed that to remove view tag instead, just to be safe.
  • Bug fix: Use of "/" in load rules for Windows jobs no longer causes all lshistory entries to be ignored. (issue #4781)
  • Bug fix: Will no longer hit NPE when attempting to delete views on rename of project when the view has never been created. (issue #4869)
  • Bug fix: Properly erroring out when we can't update a view due to an update already being in progress. (issue #4892)
  • Bug fix: Changes to load rules in base ClearCase jobs weren't being handled properly. (issue #4901)
  • Bug fix: Load rules matching in history filtering was too greedy. (issue #5012)
  • RFE: New option for base dynamic views to freeze config spec at build start time, using time rule. (issue #4652)
  • RFE: When checking out for a snapshot view, before creating a new view, Hudson now checks to see if the given view tag already exists. If so, the checkout fails and an appropriate error message is logged. (issue #4653)
  • RFE: Added advanced global option for standard view name pattern - when given, all jobs will use that for their view name, replacing variables as normal. (issue #4675)
  • RFE: Added "${OS}" as variable which can be replaced in view names with the "os.name" Java system property.
  • RFE: Added call to "startview" and "mount -avob" before lshistory is run on dynamic views. (issue #4676)
  • RFE: Advanced option for having dynamic views created, rather than solely using existing views. Still very much raw functionality - optional mkview parameters need to be specified, but there is currently no check for them. (issue #4674)
  • Also cleaned up code a lot, and got rid of deprecated calls whenever possible.

Version 1.0.2

  • Bug fix: Case sensitivity problems in extended view path comparison were introduced by the change to "lshistory -all" - they should all be cleared up now. (issue #3666, issue #4330)
  • RFE: New option to specify a polling buffer in minutes - will be subtracted from previous build's start time to determine when to poll against. (issue #3454)

Version 1.0.1

  • Bug fix: Macros in view name weren't being processed in createHistoryAction, before running cleartool pwv. (issue #4385)
  • Bug fix: Load rules in configuration can handle "load " in them properly now. (issue #4396)

Version 1.0

  • Behavior change: Requiring "load rules" to be specified (separately from config spec) for base ClearCase, and all dynamic views. This provides support for lshistory -all, and future extensions such as labeling.
  • Behavior change: Use of "lshistory -all" rather than "lshistory -recurse" - dramatic performance improvements, better change detection. Requires reconfiguration of existing jobs. This provides an enormous performance improvement in polling for jobs with large source trees.

Version 0.9.1

  • RFE: Dynamic UCM views no longer call "chstream -generate", based on this discussion.
  • Bug fix: UCM config spec wasn't using proper line endings. (issue #4027)
  • Bug fix: Forcing US locale for lshistory timestamp format, since that's what ClearCase expects. (issue #3994)

Version 0.9

  • Bug fix/behavior change: Change to config spec (for base ClearCase jobs) or load rules (for UCM ClearCase jobs) when "Use Update" is selected will no longer lead to view removal and recreation. Instead, config spec of existing view will be changed. (issue #3672)
  • Bug fix: View is properly deleted when job is deleted, workspace is deleted by automatic workspace cleanup, workspace is wiped out manually with "Wipe Out Workspace", or job is renamed, if "Remove view on rename" is selected. Also, "Remove view on rename" setting now sticks properly. (issue #2209, issue #3095, issue #3508)
  • Bug fix: Handling of line endings improved in general - modified splits, comparisons, etc to properly handle both Windows and Unix line endings. (issue #3694)
  • Behavior change: When using existing dynamic views, the ClearCase plugin will now report to the Hudson project that the "module root" is /view/view_name (or m:\view_name, or whatever is specified as the view drive), allowing for the M2 project type and the like to run from within the dynamic view.

Version 0.8.4

  • Bug fix: properly ignoring empty-string excluded regions now (issue #3622)
  • Added LICENSE.txt to src/main/resources, which will now be bundled in the hpi.

Version 0.8.3

Version 0.8.2

  • New feature: support for excludedRegions, patterns in filenames/paths to be ignored when polling for changes.
  • New feature: support $CLEARCASE_VIEWNAME and other environment variables in mkview optional parameters (issue #2994)
  • New feature: option to remove view when job name is changed (issue #3095)
  • Bug fix: fixed lshistory timing issues when master and slave are in different timezones (issue #2493)
  • Bug fix: extra newline characters in lshistory removed (issue #2801)
  • Bug fix: loading remove/create UCM snapshot view fixed (issue #2846)
  • Bug fix: no longer attempts to remove non-existent view when update only is not selected for UCM (issue #2902)
  • Bug fix: better multiplatform support (issue #2939)
  • Bug fix: better handling of multiple VOBs with UCM (issue #3097)
  • Bug fix: UCM update-only snapshot views no longer always removed/recreated (issue #3184)
  • Bug fix: support UCM dynamic view baseline creation (issue #3186)
  • Bug fix: issue with createdBaselines variable in UcmMakeBaseline (issue #3304)
  • Bug fix: if excludedRegions were not given, all changes were rejected - fixed (issue #3325)

Version 0.8.1

Version 0.7.1

  • Added Tagging support for UCM clearcase (Baselines) (issue #1649)
  • Removing jobs will now remove view from Clearcase server (issue #1050)
  • Check that config rules contains load (issue #1062)
  • All views can be listed from the configuration page (issue #1067)

Version 0.6

  • Added activity based UCM changelog.
  • Added option to not trigger build on downstream branch destroys (issue #1470, discussion)
  • Fixed problem with too many open files (issue #1921)
  • Fixed problem with Priocess leaked file descriptors (issue #1946)
  • The view-extended pathname is removed from file paths in dynamic view events (issue #1885)
  • The view name can now contain properties which are replaced before usage. ${USER_NAME} and ${JOB_NAME} (issue #1715)
  • Implemented SCM methods getModuleRoot() so the SCM can work better with builders. (issue #1848)

Version 0.5.2

  • UCM Load rules begining with double "\" or "/" no longer throws an exception when retrieving the history (issue #1706)
  • UCM Load rules no longer loses single "\" (issue #1707)

Version 0.5.1

  • Replaced setview call with startview when checking out dynamic views.(issue #1631)

Version 0.5

  • Initial support for ClearCase UCM. It can now use UCM streams and apply load rules to them. The plugin has now two SCM configuration points, Base ClearCase and UCM ClearCase. (issue #1580)
  • Changeset items are now listed in XML API (issue #1325)
  • File element changes with version 0 is now also ignored on linux/solaris (issue #1465)
  • Added CLEARCASE_VIEWPATH environment variable that contains the absolute path to the ClearCase view (issue #1480)
  • Changeset items are now marked with an icon depicting if the item was added, removed or checked in. (issue #1068)
  • Fixed so "setview" will be called on all dynamic views in every build (issue #1484)

Version 0.4

  • Added option to set additional arguments when creating the snapshot view using 'mkview'.
  • Fixed problem with merged entries so the oldest date/time is used for the merged entry.
  • Sorts the list so the latest entry is placed at top.

Version 0.3.3

  • Time window for merging commits can now grow to include all entries in one commit. (issue #1079)
  • Rephrased all "Clear case" to "ClearCase" and "clear tool" to "cleartool"

Version 0.3.2

  • Fixed issue with '^M' characters in the config spec when running on unix/linux.
  • Improved help section about view root (thanks to Jason Messmer)
  • Better error handling when the cleartool command is not set (issue #1086)

Version 0.3.1

  • Fixed a problem when the SCM object was serialized and not created through the constructor.

Version 0.3

  • Added option to use multiple branches when polling for changes (issue #1028).
  • Added functionality that checks if the config spec needs to be updated (both dynamic and snapshot) (issue #1027).
  • Added support of using existing dynamic views. The plugin will not create dynamic views.
  • Added option to use multiple VOB paths when polling for changes (issue #1053)
  • Added feature that merges change log entries that have the same user, comment and time (issue #924)
  • Fixed so the plugin will not start a "cleartool update" after the view has been updated with the "cleartool setcs" command.
  • Fixed a poll changes bug when the plugin is used by a maven job (issue #1029).
  • Fixed so plugin works with JDK1.5 (issue #1053)
  • Fixed a bug that occurred when the user removed the view, then the poll changes would throw an exception. (issue #923).

Version 0.2.1

  • Fixed a unicode problem with the change log xml file

Version 0.2

  • Reworked the plugin so it will use a config spec to retrieve files from the Clear case repository. The files are retrieved into the workspace as other SCMs.
  • Fixed so the annotation plugins works as they should
  • Added the environment variable CLEARCASE_VIEWNAME that contains the view name
  • Rewrote the history parsing to fix a NPE.
  • Added option to see the cleartool version and verify that Hudson can use it

Version 0.1

  • First version!base_standard_config.png|align=right!

Labels:

plugin-scm plugin-scm Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Nov 22, 2007

    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 :

    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. Nov 22, 2007

    Jamie Burrell says:

    Sorry - the above was by me. Forgot I hadn't logged in. Jamie

    Sorry - the above was by me. Forgot I hadn't logged in.

    Jamie

  3. Dec 11, 2007

    Anonymous says:

    Hello folks, Before bombarding you with questions about ClearCase support, I wa...

    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. Dec 12, 2007

    Jamie Burrell says:

    Mike, I'd completely recommend Hudson and ClearCase. I'm using CC6/Maven2, wit...

    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. Dec 20, 2007

    Anonymous says:

    Any plans to add UCM support?  I -think- this would boil down to th...

    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. Dec 21, 2007

    Erik Ramfelt says:

    Please use the available mailing lists for requesting features and asking questi...

    Please use the available mailing lists for requesting features and asking questions about the plugin as this wiki is not being actively monitored.

  7. Nov 06, 2008

    Jeffrey Cameron says:

    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?

  8. Nov 20, 2008

    cuiyz says:

    Hi Guys, I got a ClearCase issue like this: [<my view name>] $ cleartool...

    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"
    Added file element "a.java".
    Added file element "b.java".
    Added file element "c.java".
    ... ...
    ... ...  // 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. Nov 24, 2008

    ALU Enterprise says:

    Dear all, [...] [Qestion move. cf Mailing list] -- ALU

    Dear all,

    [...]

    [Qestion move. cf Mailing list]

    --

    ALU

  10. Jan 22, 2009

    Rüdiger Hoffner says:

    I try to use Clearcase-Plugin with Snapshot-Views. My config-spec has a large si...

    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. Mar 09, 2009

    G. Lohmann says:

    If you have an UCM View Branch Setup like: VOBs +-Features +-Integratio...

    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
    cleartool: Error: Branch type not found: "".
    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. Mar 16, 2009

    Rajesh Sarva says:

    Hi, My requirement is to apply labels on source code before build and upda...

    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. Apr 06, 2009

    Alex Earl says:

    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.

    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. Apr 07, 2009

      Alex Earl says:

      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?

  14. Apr 16, 2009

    Park Su Jin says:

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

    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. Apr 17, 2009

      Andrew Bayer says:

      Hi - We don't have the option of ignoring errors in cleartool executions, nor d...

      Hi -

      We don't have the option of ignoring errors in cleartool executions, nor do we intend to add that option. Sorry.

      A.

      1. Jun 12, 2009

        Andrey B says:

        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.

  15. Sep 18

    Duncan McLaren says:

    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.

    Has anyone else encountered these issues?

    regards

    Duncan

  16. Nov 10

    David Hausladen says:

    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.

     
    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. Jan 18

    Roshan Soni says:

    Hi, Does anyone know if this plugin supports CC 7.1? Thanks, Roshan

    Hi, Does anyone know if this plugin supports CC 7.1?

    Thanks,

    Roshan

  18. Jan 26

    Hugo Monteiro says:

    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.

    Thanks!

    1. Jan 26

      Andrew Bayer says:

      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.

  19. Feb 01

    Saravanan BV says:

    Hi, I have started using Hudson and integrated CC plugin. I am getting the fol...

    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