-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Windows 7 64 bit, Hudson version 1.366, Clearcase plugin version 1.3, IBM Rational Clearcase version 7.0.1.1
This also happen with Linux x86_64 ClearCase version 7.1.1.2
Since upgrading from Clearcase plugin version 1.2.1 to the latest release (1.3), the plugin has stopped detecting SCM changes. I am using Base Clearcase with snapshot views. The Clearcase plugin is set to poll for changes every 5 minutes.
When the build is triggered manually, the correct change history is generated, but polling never detects any changes. The Base ClearCase Polling Log shows that lsview has been run (successfully) to confirm that the view exists, but there is no sign of lshistory being called to check for updates. This was working correctly with the same job configuration using the previous release version of the plugin.
Sample polling log (with HUDSON_CLEARCASE_VERBOSE environment variable set to '1'):
Started on 16-Jul-2010 14:21:17 Running ClearCase command: pwv -root [hudson_master_VQM_CI_view] $ cleartool pwv -root C:\Users\camci\.hudson\jobs\VQM_CI\workspace\hudson_master_VQM_CI_view =============================================================== Running ClearCase command: lsview hudson_master_VQM_CI_view [workspace] $ cleartool lsview hudson_master_VQM_CI_view hudson_master_VQM_CI_view \\tekcafs1\ccview1\views1\GLOBAL\camci\hudson_master_VQM_CI_view.vws =============================================================== Done. Took 62 ms No changes
It seems that AbstractHistoryAction.runLsHistory is exiting after calling lsview but before calling lshistory. Since the lsview check is successful, the only way that could happen seems to be if the viewPaths string array parameter is empty.
138 if (ArrayUtils.isEmpty(viewPaths)) { 139 return history; 140 }
A recent change to AbstractClearCaseScm.compareRemoteRevisionWith() would seem to be the culprit.
533 if (historyAction.hasChanges(ccBaseline.getBuildTime(), viewPath, viewName, branchNames, ccBaseline.getLoadRules())) {
Looking at the revision history, it seems that this was changed recently to get the loadrules from the AbstractClearCaseSCMRevisionState passed to the compareRemoteRevisionWith() method (the call to ccBaseline.getLoadRules(). Earlier versions called AbstractClearCaseScm.getViewPaths(). However, I've looked at where the ClearCaseSCMRevisionState is created (ClearCaseSCM lines 399-407), and nothing seems to call setLoadRules() to actually set the load rules in the revision state.
Of course, I might be barking up the wrong tree with diagnosis - I only started looking at the source code today!
- is duplicated by
-
JENKINS-7104 Clearcase Plug-in 1.3 polling broken
-
- Reopened
-
Code changed in hudson
User: : vlatombe
Path:
trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/ClearCaseSCM.java
http://jenkins-ci.org/commit/32963
Log:
JENKINS-6999: Polling not working anymore with Clearcase Base