• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • clearcase-plugin
    • None
    • RedHat Linux

      I was using Hudson 1.366. After I installed the new Clearcase 1.3 plug-in, I noticed that polling no longer detected changes in my Clearcase vobs. Polling would generate a normal report, but report no issues found.

      I just updated to Hudson 1.368 and the same thing is still happening.

          [JENKINS-7104] Clearcase Plug-in 1.3 polling broken

          javakrieg added a comment -

          Here is the build.xml from the last successful build. There are 2 file changes after this build. I am trying to get the Clearcase plug-in to recognize these changes without my don't an explicit build.

          See previous comment for the output generated after rebooting the Hudson server.

          javakrieg added a comment - Here is the build.xml from the last successful build. There are 2 file changes after this build. I am trying to get the Clearcase plug-in to recognize these changes without my don't an explicit build. See previous comment for the output generated after rebooting the Hudson server.

          Do you specify any load rule for your job? If none is specified, the plug-in currently doesn't try to call lshistory. Maybe the plug-in behaviour should be changed to check for all paths inside the view root if no load rule is specified.

          Vincent Latombe added a comment - Do you specify any load rule for your job? If none is specified, the plug-in currently doesn't try to call lshistory. Maybe the plug-in behaviour should be changed to check for all paths inside the view root if no load rule is specified.

          eraonel added a comment -

          Hi,

          I think I know what the problem is:

          /usr/atria/bin/cleartool lshistory -all -since 6-aug-10.19:31:10utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:hudson_gem_developer_view -nco vobs/c

          has wrong vob-path.

          Should be:

          /vobs/mxutil

          I will check the code an see if it is easy to fix.

          br,

          //mike

          eraonel added a comment - Hi, I think I know what the problem is: /usr/atria/bin/cleartool lshistory -all -since 6-aug-10.19:31:10utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:hudson_gem_developer_view -nco vobs/c has wrong vob-path. Should be: /vobs/mxutil I will check the code an see if it is easy to fix. br, //mike

          gwyrlim added a comment -

          Is there a workaround for it or are a solution on the way? I tried fixing it my self but I's to many new things for me to handle at the moment.

          gwyrlim added a comment - Is there a workaround for it or are a solution on the way? I tried fixing it my self but I's to many new things for me to handle at the moment.

          eraonel added a comment -

          Hi,

          I have looked at the one test case that where viewpath is changed to filepath. What is the relevance of this line:

          List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[]

          {"Release_2_1_int"}, new String[]{"vobs/projects/Server"});

          Is is a viewpath that is unrelated to what is defined in cleartool command. Also I can see that getChanges() is used in test code only but not in prod. code. Is this method replaced?

          br,

          //mike

          public void assertViewPathIsRemovedFromFilePaths() throws Exception {
          context.checking(new Expectations() {
          { one(cleartool).lshistory(with(any(String.class)), with(any(Date.class)), with(any(String.class)), with(any(String.class)), with(any(String[].class))); will(returnValue(new StringReader( "\"20070827.085901\" \"user\" \"action\" \"/view/ralef_0.2_nightly/vobs/Tools/framework/util/QT.h\" \"/main/comain\" \"mkelem\"\n"))); }
          });

          BaseChangeLogAction action = new BaseChangeLogAction(cleartool, 1000,null);
          action.setExtendedViewPath("/view/ralef_0.2_nightly");
          List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[]{"Release_2_1_int"}

          , new String[]

          {"vobs/projects/Server"}

          );
          assertEquals("Number of history entries are incorrect", 1, entries.size());
          ClearCaseChangeLogEntry entry = entries.get(0);
          assertEquals("File path is incorrect", "/vobs/Tools/framework/util/QT.h", entry.getElements().get(0).getFile());
          }

          eraonel added a comment - Hi, I have looked at the one test case that where viewpath is changed to filepath. What is the relevance of this line: List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[] {"Release_2_1_int"}, new String[]{"vobs/projects/Server"}); Is is a viewpath that is unrelated to what is defined in cleartool command. Also I can see that getChanges() is used in test code only but not in prod. code. Is this method replaced? br, //mike public void assertViewPathIsRemovedFromFilePaths() throws Exception { context.checking(new Expectations() { { one(cleartool).lshistory(with(any(String.class)), with(any(Date.class)), with(any(String.class)), with(any(String.class)), with(any(String[].class))); will(returnValue(new StringReader( "\"20070827.085901\" \"user\" \"action\" \"/view/ralef_0.2_nightly/vobs/Tools/framework/util/QT.h\" \"/main/comain\" \"mkelem\"\n"))); } }); BaseChangeLogAction action = new BaseChangeLogAction(cleartool, 1000,null); action.setExtendedViewPath("/view/ralef_0.2_nightly"); List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[]{"Release_2_1_int"} , new String[] {"vobs/projects/Server"} ); assertEquals("Number of history entries are incorrect", 1, entries.size()); ClearCaseChangeLogEntry entry = entries.get(0); assertEquals("File path is incorrect", "/vobs/Tools/framework/util/QT.h", entry.getElements().get(0).getFile()); }

          Hi,

          > List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[]

          {"Release_2_1_int"}

          , new String[]

          {"vobs/projects/Server"}

          );
          > Is is a viewpath that is unrelated to what is defined in cleartool command.

          It is unimportant what is the last path, since lshistory is not actually called in the testcase. Call to lshistory will be replaced by Expectations object, which will return value as specified (regardless of arguments - see all those with(any(...))). What this test does is checking that viewpath is removed from lshistory output (so that "/view/ralef_0.2_nightly/vobs/Tools/framework/util/QT.h" is converted to "/vobs/Tools/framework/util/QT.h").

          > Also I can see that getChanges() is used in test code only but not in prod. code. Is this method replaced?

          No, it isn't. It is called in AbstractClearCaseScm.saveChangeLog() which in turn is called in AbstractClearCaseScm.checkout().

          Krzysztof Malinowski added a comment - Hi, > List<ClearCaseChangeLogEntry> entries = action.getChanges(new Date(), "IGNORED", new String[] {"Release_2_1_int"} , new String[] {"vobs/projects/Server"} ); > Is is a viewpath that is unrelated to what is defined in cleartool command. It is unimportant what is the last path, since lshistory is not actually called in the testcase. Call to lshistory will be replaced by Expectations object, which will return value as specified (regardless of arguments - see all those with(any(...))). What this test does is checking that viewpath is removed from lshistory output (so that "/view/ralef_0.2_nightly/vobs/Tools/framework/util/QT.h" is converted to "/vobs/Tools/framework/util/QT.h"). > Also I can see that getChanges() is used in test code only but not in prod. code. Is this method replaced? No, it isn't. It is called in AbstractClearCaseScm.saveChangeLog() which in turn is called in AbstractClearCaseScm.checkout().

          eraonel added a comment -

          Hi,

          Thanks for pointing it out. Do you have a cc installation on Hudson? Since I do not have access to clearcase and Hudson at the moment.
          My idea is now simply to add some trace in ClearToolExec for lshistory since I could see that vob-path is missing a / at the beginning.
          I want to print out the following parameters and see what they are set to:

          • viewPath
          • filePath
          • path

          Can I add trace and send new hpi file so anyone can capture the trace?

          br,

          //mike

          eraonel added a comment - Hi, Thanks for pointing it out. Do you have a cc installation on Hudson? Since I do not have access to clearcase and Hudson at the moment. My idea is now simply to add some trace in ClearToolExec for lshistory since I could see that vob-path is missing a / at the beginning. I want to print out the following parameters and see what they are set to: viewPath filePath path Can I add trace and send new hpi file so anyone can capture the trace? br, //mike

          Hi,

          vob path has initial / stripped by design. You see, vobs are not always available at root directory, you are probably tempted to think about vobs through the dynamic view which is set. However, the same vob could be available as /vobs/product in set dynamic view, as /view/some_view/vobs/product in dynamic view which is not set or as /usr/raspy/snapshots/snapshot_view/vobs/product in some snapshot view. Therefore what the plugin does is entering view path and then running lshistory for relative path (without /) vobs/product. Depending on configuration (dynamic/snapshot view and path) the working directory will be different, but the lshistory call can be the same.

          See the console log that after 'cleartool startview' command, the current directory is no longer [workspace] when running lshistory.

          I could make use of your trace plugin if you wish, but if its purpose is to check why / is stripped, I tell you now: it's by design

          Best regards,
          raspy

          Krzysztof Malinowski added a comment - Hi, vob path has initial / stripped by design. You see, vobs are not always available at root directory, you are probably tempted to think about vobs through the dynamic view which is set. However, the same vob could be available as /vobs/product in set dynamic view, as /view/some_view/vobs/product in dynamic view which is not set or as /usr/raspy/snapshots/snapshot_view/vobs/product in some snapshot view. Therefore what the plugin does is entering view path and then running lshistory for relative path (without /) vobs/product. Depending on configuration (dynamic/snapshot view and path) the working directory will be different, but the lshistory call can be the same. See the console log that after 'cleartool startview' command, the current directory is no longer [workspace] when running lshistory. I could make use of your trace plugin if you wish, but if its purpose is to check why / is stripped, I tell you now: it's by design Best regards, raspy

          eraonel added a comment -

          Hi,

          ok so you are saying that vob path has the / removed. And when the lshistory is executed is uses working directory (depending on dynamic or snapshot) and the stripped vobpath.
          Then ignore my above suggestion.

          br,

          //mike

          eraonel added a comment - Hi, ok so you are saying that vob path has the / removed. And when the lshistory is executed is uses working directory (depending on dynamic or snapshot) and the stripped vobpath. Then ignore my above suggestion. br, //mike

          On my instance it doesn't even try to run lshistory:

          Started on Apr 11, 2012 2:16:16 PM
          [jenkins_psd48_Inspect_and_Analyze_jenkins] $ cleartool pwv -root
          [Inspect_and_Analyze] $ cleartool lsview jenkins_psd48_Inspect_and_Analyze_jenkins
          Done. Took 0.14 sec
          No changes

          Is this plugin still being actively developed? This is a large issue and hasn't been updated in a while.

          Jordan Bentley added a comment - On my instance it doesn't even try to run lshistory: Started on Apr 11, 2012 2:16:16 PM [jenkins_psd48_Inspect_and_Analyze_jenkins] $ cleartool pwv -root [Inspect_and_Analyze] $ cleartool lsview jenkins_psd48_Inspect_and_Analyze_jenkins Done. Took 0.14 sec No changes Is this plugin still being actively developed? This is a large issue and hasn't been updated in a while.

            Unassigned Unassigned
            javakrieg javakrieg
            Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: