Allows using ClearCase UCM baselines as the input of builds: When using
this SCM, users will be asked at build-time to select the baseline on
which the job has to work.

To use this plugin, you need to install the [ClearCase
Plugin](https://wiki.jenkins.io/display/JENKINS/ClearCase+Plugin) since it
relies on it (more precisely, the global configuration data is shared
between the two plugins):

[TABLE]

# About this plugin

This plugin adds a new **ClearCase UCM baseline** SCM mode to the
projects: It's then possible for a build to start based on a ClearCase
UCM baseline (composite or not) without playing with config specs or
having to modify the job configuration. When using the **ClearCase UCM
baseline** SCM mode, the user will be presented with the following
screen when starting a new build:

![](docs/images/clearcase-ucm-baseline-02.png)

After having clicked on the **Build** button of this screen, a new view
will be created to retrieve the whole content of the selected baseline
and the job will be able to work on this data, as usually.

# A use case behind this plugin

Let's say your development team is using Hudson as their continuous
integration system while developing a new J2EE application. They have
defined a new job in Hudson, which runs twice a day (at noon and at
night) to frequently ensure everything works fine. This job may do the
following:

1.  It gathers the application source code using the [ClearCase
    Plugin](https://wiki.jenkins.io/display/JENKINS/ClearCase+Plugin).
2.  It builds the application from the source code using the [RAD
    Builder
    Plugin](https://wiki.jenkins.io/display/JENKINS/RAD+Builder+Plugin).
3.  It runs the unit tests (thank you JUnit).
4.  It deploys the application on a production-like application server
    (for example using the [WAS Builder
    Plugin](https://wiki.jenkins.io/display/JENKINS/WAS+Builder+Plugin)),
    ensuring everything is deployed properly (e.g. JDBC resources are
    available, etc.).
5.  It triggers the execution of non-regression testing.
6.  At one moment or another in this build-flow (depending on your point
    on view), it creates a new ClearCase baseline.

After some time, once the application has been extensively tested and
when most of its functionalities are considered as ready-for-production,
one of the baseline is promoted to the RELEASED level. It means your
infrastructure team will gather this baseline and deploy on the
production environment what has to be deployed.  
Hey, minute, we're talking about deployment, right? Something has
already been defined in the previously described job to do that! It has
run many many times, so it can also surely be used to perform the
deployment on the production environment, no? This is when the ClearCase
UCM Baseline Plugin comes in: It allows you to reuse what has already
been defined in Hudson but to work on promoted baselines rather than
working on the HEAD revision.

# User guide

There's not much to say here, refer to the inline help (the little
question marks at the right of the jobs' configuration screen) to get
detailed information:

-   Set the SCM to be **ClearCase UCM baseline**. You'll notice that it
    has no parameters (screenshot below).
-   If not already done, activate the **This build is parameterized**
    option.
-   Add one (and only one) **ClearCase UCM baseline** parameter and fill
    the various fields.
-   You're done!

![](docs/images/clearcase-ucm-baseline-01.png)

Now, when starting a new build, the user will be offered with a
drop-down list allowing him to chose one of the baselines based on the
job's settings:

![](docs/images/clearcase-ucm-baseline-02.png)

Some questions and their answers regarding the configuration of this
plugin:

-   What if I define the SCM to be **ClearCase UCM baseline** but
    without adding the required parameter?  
    *The build will fail, explaining why.*
-   What if I define the SCM to be **ClearCase UCM baseline** but adding
    more than one **ClearCase UCM baseline** parameter?  
    *The build will fail explaining why.*
-   What if I don't set the SCM to be **ClearCase UCM baseline** but
    adding some **ClearCase UCM baseline** parameter?  
    *Here also, the build will fail explaining why.*
-   What if I create a string parameter named **ClearCase UCM baseline**
    (using the **ClearCase UCM baseline** mode)?  
    *The build will fail, explaining why.*

# Roadmap

# Known limitations

-   The plugin will not work when using it for a job which is not tied
    to a specific node: It won't be able to get the baselines list
    before the build is actually assigned to a node.

# Version history

## Version 1.7.4 (09/19/2011)

-   Implemented
    [JENKINS-9074](https://issues.jenkins-ci.org/browse/JENKINS-9074): A
    warning message is now displayed if both the **Exclude element
    CHECKEDOUT** and **Use snaphost view** options are checked

## Version 1.7.3 (02/20/2011)

-   Implemented
    [HUDSON-8013](http://issues.hudson-ci.org/browse/HUDSON-8013):
    -   Baselines are now displayed from the most recent one to the
        oldest one.
    -   Added a new **More recent than** field which allows displaying
        only baselines more recent than a given duration.
-   Implemented
    [HUDSON-8015](http://issues.hudson-ci.org/browse/HUDSON-8015):
    Baselines description are now displayed in builds log.
-   Fixed
    [JENKINS-8695](http://issues.jenkins-ci.org/browse/JENKINS-8695):
    Baselines spread across several PVOBs are now properly handled.

## Version 1.7.2 (01/21/2011)

-   Fixed [HUDSON-8168](http://issues.hudson-ci.org/browse/HUDSON-8168):
    The `cleartool` command was wrongly generated when adding the `-stg`
    option in the **Additional mkview arguments** field.

## Version 1.7.1 (10/01/2010)

-   Fixed an issue which was preventing to use snapshot views.

## Version 1.7 (09/02/2010)

-   Compatibility with the 1.3.x versions of the ClearCase plugin –
    Compatibility with 1.0.x, 1.1.x and 1.2.x has been dropped.

## Version 1.6 (06/23/2010)

-   Upward compatibility with the 1.2.x versions of the ClearCase plugin
    (still supporting the 1.0.x and 1.1.x versions).
-   Added an option to specify additional `mkview` arguments (cf.
    [HUDSON-6409](http://issues.hudson-ci.org/browse/HUDSON-6409)).
-   Added the possibility to use the `CLEARCASE_BASELINE` environment
    variable within the view name (cf.
    [HUDSON-6410](http://issues.hudson-ci.org/browse/HUDSON-6410)).
-   Added a new option to exclude `element * CHECKEDOUT` from config
    specs (cf.
    [HUDSON-6411](http://issues.hudson-ci.org/browse/HUDSON-6411)).
-   Fixed [HUDSON-6398](http://issues.hudson-ci.org/browse/HUDSON-6398):
    -   Rootless components are now no more taken into account.
    -   Load rules are no more duplicated under certain conditions.

## Version 1.5.1 (04/02/2010)

-   Fixed [HUDSON-6152](http://issues.hudson-ci.org/browse/HUDSON-6152):
    -   No config spec elements/load rules were generated for the
        selected baseline.
    -   The config spec was not used.

## Version 1.5 (03/29/2010)

-   Added a new **Stream** option to filter the displayed baselines (cf.
    [HUDSON-6088](http://issues.hudson-ci.org/browse/HUDSON-6088)).
-   Added a new **Use update** option to avoid recreating the view each
    time a new build is triggered (cf.
    [HUDSON-6088](http://issues.hudson-ci.org/browse/HUDSON-6088) too).
-   Fixed [HUDSON-6057](http://issues.hudson-ci.org/browse/HUDSON-6057):
    The plugin will try to start the node it is tied to if it is
    offline.
-   Fixed [HUDSON-6029](http://issues.hudson-ci.org/browse/HUDSON-6029):
    The plugin will behave properly in a mixed Linux/Windows environment
    (e.g. the master being Linux and slaves being either Linux or
    Windows).
-   Fixed [HUDSON-5877](http://issues.hudson-ci.org/browse/HUDSON-5877):
    Added a new error message to clearly show that the publishers (make
    baseline and make composite baseline) from the [ClearCase
    plugin](https://wiki.jenkins.io/display/JENKINS/ClearCase+Plugin)
    can't be used with the **ClearCase UCM baseline** SCM mode.

## Version 1.4 (03/02/2010)

-   Added a new **Use snapshot view** option (activated per default).
-   The plugin now better handles '/' characters in front of PVOB names:
    If '/' is/was not specified, it will be automatically added.
-   The VOB parameter has been removed. If you get the following
    exception, you can safely ignore it:
    ``` syntaxhighlighter-pre
    ATTENTION: Skipping a non-existent field vob
    com.thoughtworks.xstream.converters.reflection.NonExistentFieldException: No such field com.michelin.cio.hudson.plugins.clearcaseucmbaseline.ClearCaseUcmBaselineParameterValue.vob
    ```

-   The component root dir is now retrieved from the specified
    component; In earlier releases, the plugin assumed that the
    component root dir was identical to the name of component.

## Version 1.3 (02/24/2010)

-   Upward compatibility with the 1.1.x versions of the ClearCase plugin
    (still supporting the 1.0.x versions).
-   Added a new **Force rmview** option: If the baseline selected for
    build \#*n* is the same as for build \#*n-1* (and if the
    corresponding view still exists), by default the view won't be
    created/loaded again; Set this option to true so that the view gets
    recreated anyway.
-   Fixed an issue which was displaying an incorrect view name in
    builds' history.

## Version 1.2 (02/08/2010)

-   Added a new **CLEARCASE\_BASELINE** environment variable.

## Version 1.1 (01/22/2010)

-   Added a new **Restrict folders to** field which allows defining
    which folders have to be actually downloaded from the ClearCase UCM
    baseline.

## Version 1.0.1 (01/11/2010)

-   Fixed an issue which was preventing to display the list of the
    baselines when the job was running on a tied slave node

## Version 1.0 (01/10/2010)

-   Initial release