A Praqmatic integration to ClearCase UCM, simplifying continuous integration with Jenkins.
If you use this plugin - please share your current usage of it - and read what others have achieved:
If you are using base ClearCase you should use the old plugin. If you are using ClearCase UCM you should use this one.
Do you wonder why there is a separate plugin for ClearCase UCM? - Please read the blog post on "The rationale behind the ClearCase UCM plugin for Jenkins CI"! Also read some of the attendees reactions on this plugin as it was presented on Jenkins User Conference in Paris, april 2012 or get into depth with pre-tested commits described in our paper on the subject.
Older versions of the plugin can be found and downloaded here
The following image is the entire configuration paragraph of the ClearCase UCM Plugin
Essentially the plugin is looking for new baselines on a specific stream belonging to a specify stream. On top op that you have to qualify which baselines are of interest in this context by applying a Promotion Level. Only baselines found that matches all three parameters will kick off the build.
When the build ends, the promotion level will either be stepped one level up (if successful) or rejected.
If you have a configuration where you use more than one component in your foundation, you may wonder why we only left room for specifying one single component - please take the time require to read the blog post on "[The rationale behind the ClearCase UCM plugin for Jenkins CI|http://www.praqma.com/stories/ccucm]"
The plugin will automatically create a snapshot view in a folder named 'view' in the root of the job's workspace. Snapshot views can - as opposed to dynamic views - be located anywhere, which we exploit to place it inside the job's workspace. Dynamic Views can only reside on the location where your mvfs is located and that is not inside the workspace.
A lot of plugins have browsing features, that allows you to see the code in the browser, high-lighted to make a point in the context (warnings, violations, code coverage...) In order to guarantee compliancy with these type of plugins we only support snapshot views.
In general build performance is also much better in snapshot views that are hosted by the clients native file system - once they are loaded.
We us a separate view per job, per client, which allows us to reuse views in a context the only changes very little between builds. Thus you will find that once you have loaded the view the first time, the successive updates will be very fast, since deltas are guaranteed to be small.
You have a small handle of control of what load-rules are applied to the snapshot views; Either you load all the components or only the modifiable ones.
Some of the features in the post build section to the plugin such as the pre-tested delivery features available in poll child and poll sibling mode, and the 'Recommend baseline' checkbox ways to make boolean decisions; complete or cancel? Recommend or not? But the outcome of a Jenkins job really has three possible states; Succes, unstable and failure. You will have to decide if the unstable state should due treated as success or failure.
If the checkbox Recommend baseline is set, a successful build will recommend the baseline that was used.
When the checkbox Make tag is checked, the plugin will persist the build status in ClearCase, by writing a small summary of the status as a to-text object at the end of a hyperlink of type tag attached to the baseline.
NOTE:The if you want to use this feature then the hltype:tag should be created first
When Set description is checked, the build description in the left margin of the job page is updated with the details of the build. Super crisp feature! Check i out!
ClearCase UCM Plugin supports three types of polling modes.
Self mode enables you to find baselines on the stream itself given a promotion level.
If the build is successful, the plugin can recommend the baseline and it will promote it to the next level.
If the build has failed, the plugin will demote the baseline to rejected.
About the streams created in this mode, see the advanced section.
Note that this is the only mode creating auxiliary streams.
This mode enables you to find baselines on related streams of the target stream. This is either development streams of the target stream(child mode) or other integration streams having this stream as default target(sibling mode).
If the build is successful, the baseline is delivered to the target stream and you can choose to create a baseline on it. The baseline of the other stream is promoted to the next level.
The plugin can recommend the new baseline on the target stream.
If the build has failed, the plugin will demote the baseline of the other stream to rejected and no deliver activity is made, and thus no baseline is created on the target stream.
The option Create baseline and Name template enables you to create a baseline on the target stream. The name template is made up of free text with optional keywords, expanding to run time variables:
Keywords are enclosed in square brackets(). For example [project][date][time] will result in the baseline myproject_20110915_1128.
The plugin's baseline naming feature is meant to run on the UCM Project's default baseline naming template just containing "basename".
Although "basename" CAN be combined with other keywords in the template - it can not be entirely omitted. It's highly recommended, that if you want to use the plugin's baseline naming strategy you reset the UCM projects naming template to it's default.
Notice that this option has no meaning for self polling or if the Create baseline option is not checked.
Like the Git and Mercurial plugins, ClearCase UCM Plugin also supports polling for the latest baseline. This means, when polling, a build is scheduled only if there's a new baseline on the stream.
To be able to poll for the latest baseline, the special promotion level ANY and self polling must must be selected in the setup.
Parameterizing your build with a string called baseline will let you build a specific named baseline. This baseline name is the value of the parameter. This feature will let you have one job, that does the polling on SCM and then has a post-build step orchestrated by the Parameterized Trigger Plugin which builds the same baseline. The downstream job, should have the same settings for stream and component - and if you set the promotion level to ANY, the downstream job will not change the built baseline's promotion level.
The ClearCase UCM plugin introduces several build variables:
Jenkins needs to be authenticated by ClearCase, so it's important that you run the Jenkins service under an account that has the sufficient access to ClearCase. The ClearCase UCM Plugin fully supports that a slave can be in a different ClearCase region or even at a completely different ClearCase MultiSite than the master.If you utilize this feature, it's required that the slave is running Jenkins under an account which has the sufficient credential on the remote site
The plugin will state in the console output, when ClearCase is not available. This concerns both when it is not installed and when there are no licenses available. If a build has been scheduled, its description is set with the cause.
If you don't get any scheduled builds, check your poll log. This is where to find information, if ClearCase is unavailable.
If you have slaves in different MultiSites than the master, you can tie the jobs that monitors stream that has mastership on foreign sites to slaves that belongs to those sites. A simple strategy for this is that you add a tag to all you slaves telling which MultiSite they belong to and then you tie the jobs to those labeled slaves.
The plugin supports polling for posted deliveries in a MultiSite environment. This feature must be turned on at the Jenkins global settings for the plugin, and only has effect in child polling mode. Normally in this mode, the plugin will harvest all baselines made in child streams. If the stream is at a different site, this is not possible. In this setup, the plugin can work in two different modes:
For debugging purposes a job can be parametrized to output debug log information to a file. The parameters are string parameters.
Note that these names are case sensitive!
The logs can be found in the jobs build folder under each specific build folder where the debug has been enabled. This means you have to browse into the master Jenkins server.
The SCM log is named ccucmSCM.log and the post-build log is named ccucmNOTIFIER.log.
From version 1.2.0 the Logging Plugin is required.
So install the Logging Plugin and restart Jenkins, then go to the Job Configuration for the job, and enable logging, use "net.praqma" as logger name:
and then you will find links to the logs from the jobs front page:
This release includes a major bump in Jenkins core requirements. This was done in order to implement the change listed below. Users of a Jenkins version older than 1.534 should use version 1.4.4
Note: (Only)This release mistakenly will never process baselines again even though the promotion level is flipped manually.
Skip to end of metadata Go to start of metadata