• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • clearcase-plugin
    • None
    • Windows 7

      I am using the Clearcase plugin to poll for changes and trigger a build. However, even when changes are clearly present, no build is triggered. Here's the log from a poll showing a change:

      Started on Feb 27, 2012 5:05:09 PM
      [baileyj_master_Build_OF012_hudson] $ "c:\Program Files\IBM\RationalSDLC\ClearCase\bin\cleartool" pwv -root
      C:\Users\baileyj\.jenkins\jobs\Build OF012\workspace\baileyj_master_Build_OF012_hudson
      [workspace] $ "c:\Program Files\IBM\RationalSDLC\ClearCase\bin\cleartool" lsview baileyj_master_Build_OF012_hudson
      baileyj_master_Build_OF012_hudson \\ds-wccreg2.ds.ad.foo.com\viewstore\DS\baileyj\baileyj_master_Build_OF012_hudson.vws
      [baileyj_master_Build_OF012_hudson] $ "c:\Program Files\IBM\RationalSDLC\ClearCase\bin\cleartool" lshistory -all -since 28-feb-12.00:46:58utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -branch brtype:of012 -nco web2000/of_app/of
      "20120227.170348" "baileyj" "C:\Users\baileyj\.jenkins\jobs\Build OF012\workspace\baileyj_master_Build_OF012_hudson\web2000\mm_app\we\sdk\test\autoload\ofadmin.ppk" "\main\of012\4" "create version" "checkin"

      Done. Took 0.93 sec
      No changes

      As should be clear, the file "ofadmin.ppk" shows a change, but the plugin did not detect it.

      I'm running Jenkins v1.451 and ClearCase Plug-in v1.3.7.

      If there is a mailing list where I can ask this question, please let me know.

          [JENKINS-12911] Clearecase Plugin Not Detecting Changes

          SCM polling should not be run on master. First of all, Clearcase view or its config spec can be invalid on master due to different regions/VOB tags. In situation when you have Unix/Windows clients it's quite frequent to have VOBs registered at different VOB tags, since Windows does not allow hierarchical VOB tags (like /vob/vob1). Therefore if the build should be run on Windows, it cannot be polled on Unix since config spec may be invalid (and vice versa).

          As a matter of the fact master node is not even required to have Clearcase installed. My Jenkins configuration has a master node with no executors, it only connects to slaves to run the builds. Polling at master would have no sense in this situation.

          Krzysztof Malinowski added a comment - SCM polling should not be run on master. First of all, Clearcase view or its config spec can be invalid on master due to different regions/VOB tags. In situation when you have Unix/Windows clients it's quite frequent to have VOBs registered at different VOB tags, since Windows does not allow hierarchical VOB tags (like /vob/vob1). Therefore if the build should be run on Windows, it cannot be polled on Unix since config spec may be invalid (and vice versa). As a matter of the fact master node is not even required to have Clearcase installed. My Jenkins configuration has a master node with no executors, it only connects to slaves to run the builds. Polling at master would have no sense in this situation.

          Thomas Birkl added a comment -

          Actually for this defect this is a workaround that at least works.
          Of course I'm aware of hierarchical VOB tags (which we also use).
          In our case we do polling and (Unix) view cleanup on Unix and call the
          compile job on the Windows slave, which uses the same view.
          Although they have different tags, the compile spec from Unix works on the Windows client.
          (ClearCase works with oids, so the Unix view works with Unix compiled rules also on Windows!)
          As our PCs are diskless and have no local storage, they use Unix views anyway.

          However, if there is one I'd appreciate any other workaround that helps.
          This comment was also intended as hint to analyze the issue which seems
          to be specifically related to the master/slave platform change.

          Thomas Birkl added a comment - Actually for this defect this is a workaround that at least works. Of course I'm aware of hierarchical VOB tags (which we also use). In our case we do polling and (Unix) view cleanup on Unix and call the compile job on the Windows slave, which uses the same view. Although they have different tags, the compile spec from Unix works on the Windows client. (ClearCase works with oids, so the Unix view works with Unix compiled rules also on Windows!) As our PCs are diskless and have no local storage, they use Unix views anyway. However, if there is one I'd appreciate any other workaround that helps. This comment was also intended as hint to analyze the issue which seems to be specifically related to the master/slave platform change.

          Timothy Lantz added a comment - - edited

          I'm not using hierarchical view tags but we are doing builds with Jenkins using ClearCase on both Windows and Linux. My master is Windows (due to environment constraints) and we have both Windows and Linux slaves. I see this issue for projects built on the Linux slaves.

          The issue is the same as described above - it lists changes in the polling log. However, it doesn't pick them up and at the end says No Changes. It is reproducible on two mainline builds of the same codebase. The only thing that differs in the ClearCase portion is the view tag.

          Master machine is Windows Server 2008.

          Timothy Lantz added a comment - - edited I'm not using hierarchical view tags but we are doing builds with Jenkins using ClearCase on both Windows and Linux. My master is Windows (due to environment constraints) and we have both Windows and Linux slaves. I see this issue for projects built on the Linux slaves. The issue is the same as described above - it lists changes in the polling log. However, it doesn't pick them up and at the end says No Changes. It is reproducible on two mainline builds of the same codebase. The only thing that differs in the ClearCase portion is the view tag. Master machine is Windows Server 2008.

          Timothy Lantz added a comment -

          I was poking around a bit further. It looks like using the same version of the plugin, but changing Jenkins versions reproduces the problem. If I run on 1.424, the plugin correctly gets the path separators by checking RemoteLaucher.isUnix() (which returns true). However, now on Jenkins 1.518, it is producing a Windows separator matching expression by using isUnix on the hudson.Launcher that gets passed in, which is returning false.

          Haven't had a chance to dig deeper, but will try later tonight or tomorrow.

          Timothy Lantz added a comment - I was poking around a bit further. It looks like using the same version of the plugin, but changing Jenkins versions reproduces the problem. If I run on 1.424, the plugin correctly gets the path separators by checking RemoteLaucher.isUnix() (which returns true). However, now on Jenkins 1.518, it is producing a Windows separator matching expression by using isUnix on the hudson.Launcher that gets passed in, which is returning false. Haven't had a chance to dig deeper, but will try later tonight or tomorrow.

          Timothy Lantz added a comment -

          Poking more - I think this may be specific to when the RemoteLauncher is decorated by an environment. The anonymous inner class for this case in Launcher.java doesn't override isUnix. So what happens is that the path check ends up being run instead (from the basic Launcher), and the isUnix variable that is normally taken from the SlaveComputer gets ignored.

          Seems like a simple change, but not sure what else it may break. I will give it a try.

          Timothy Lantz added a comment - Poking more - I think this may be specific to when the RemoteLauncher is decorated by an environment. The anonymous inner class for this case in Launcher.java doesn't override isUnix. So what happens is that the path check ends up being run instead (from the basic Launcher), and the isUnix variable that is normally taken from the SlaveComputer gets ignored. Seems like a simple change, but not sure what else it may break. I will give it a try.

          Timothy Lantz added a comment -

          For me, the problem is fixed with a build of 1.520 (see linked JIRA) - perhaps someone else can confirm as well?

          Timothy Lantz added a comment - For me, the problem is fixed with a build of 1.520 (see linked JIRA) - perhaps someone else can confirm as well?

          Thomas Birkl added a comment -

          Sounds good!
          v1.520 is not yet offered for me for update (1.519 is latest).
          I'll test it and post a note as soon as it's available.

          Thomas Birkl added a comment - Sounds good! v1.520 is not yet offered for me for update (1.519 is latest). I'll test it and post a note as soon as it's available.

          I just updated to 1.520 and now it works fine.

          Rudolf Honegger added a comment - I just updated to 1.520 and now it works fine.

          Thomas Birkl added a comment -

          Updated yesterday to 1.520.
          Seems to detect changes properly now over misc. platforms (Linux Slave - Windows Master),
          which did not work before.

          Thomas Birkl added a comment - Updated yesterday to 1.520. Seems to detect changes properly now over misc. platforms (Linux Slave - Windows Master), which did not work before.

          I'm closing as fixed even if the bug was not in the plugin but rather in Jenkins core. Issue is fixed in Jenkins 1.520+

          Vincent Latombe added a comment - I'm closing as fixed even if the bug was not in the plugin but rather in Jenkins core. Issue is fixed in Jenkins 1.520+

            vlatombe Vincent Latombe
            m4dc4p Justin Bailey
            Votes:
            6 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: