Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-1053

Allow lshistory from specified directory

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • clearcase-plugin
    • None
    • Platform: All, OS: Linux

    Description

      Our repo is set up in a way that when I have a load rule in my config spec like
      "load vobs/gtx2", the lshistory command is getting run in the snapshot view at
      the parent of that and gets an error because, apparently, "vobs" is not a vob
      element.

      It would be nice if you could specify a specific path to feed into the lshistory
      command. For me, "vobs/*" works from the command line.

      Here's the error output in case it helps:

      Done loading "/vobs/gtx2" (16879 objects, copied 0 KB).
      [snapshot14_cruise1_fhudson_feature_6.43_20071120] $ cleartool lshistory -r
      -since 28-Nov.15:30:38 -fmt '\"%Nd\" \"%u\" \"%e\" \"%En\" \"%Vn\"\n%c\n'
      -branch feature_6.43 -nco update.28-Nov-07.16:03:36.updt vobs .view.stg .view.dat
      cleartool: Error: Not an object in a vob: "update.28-Nov-07.16:03:36.updt".
      cleartool: Error: Not an object in a vob: "vobs".
      cleartool: Error: Not an object in a vob: ".view.stg".
      cleartool: Error: Not an object in a vob: ".view.dat".
      FATAL: Clear Case failed. exit code=1
      FATAL: Clear tool did not return the expected exit code. Command line="cleartool
      lshistory -r -since 28-Nov.15:30:38 -fmt \"%Nd\" \"%u\" \"%e\" \"%En\"
      \"%Vn\"\n%c\n -branch feature_6.43 -nco update.28-Nov-07.16:03:36.updt vobs
      .view.stg .view.dat", actual exit code=1
      java.io.IOException: Clear tool did not return the expected exit code. Command
      line="cleartool lshistory -r -since 28-Nov.15:30:38 -fmt \"%Nd\" \"%u\" \"%e\"
      \"%En\" \"%Vn\"\n%c\n -branch feature_6.43 -nco update.28-Nov-07.16:03:36.updt
      vobs .view.stg .view.dat", actual exit code=1
      at hudson.plugins.clearcase.ClearCaseSCM.run(ClearCaseSCM.java:272)
      at hudson.plugins.clearcase.ClearCaseSCM.getHistoryEntries(ClearCaseSCM.java:247)
      at hudson.plugins.clearcase.ClearCaseSCM.checkout(ClearCaseSCM.java:117)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:541)
      at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:223)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:189)
      at hudson.model.Run.run(Run.java:649)
      at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:172)
      at hudson.model.ResourceController.execute(ResourceController.java:70)
      at hudson.model.Executor.run(Executor.java:62)

      Attachments

        Activity

          redsolo redsolo added a comment -

          This seems to be a linux/solaris issue, as when creating the view it will
          download the specified VOBs into a folder named vobs, right? When running the
          same command in Windows, it will create folders for each vob in the view folder.

          BTW, what is the vob name in your setup? "vobs" or "gtx2"? If it is, can you
          specify "load /gtx2" instead of "load vobs/gtx2", and see what happens?

          Example with three VOBs. (vob1, vob2, vob3)
          Configspec:
          load \vob1\CM
          load \vob2\Source
          load \vob3\CM

          windows:
          local_view\vob1
          local_view\vob2
          local_view\vob3

          linux:
          local_view\vobs\vob1
          local_view\vobs\vob2
          local_view\vobs\vob3

          Is this assumption correct in linux?

          Anyhow, you can download the latest version from http://hudson.ramfelt.se, as it
          has a text field for specifying the VOB paths. In the text field you would
          specify "vobs/vob1 vobs/vob2". Please try it and let me know how it works out.

          redsolo redsolo added a comment - This seems to be a linux/solaris issue, as when creating the view it will download the specified VOBs into a folder named vobs, right? When running the same command in Windows, it will create folders for each vob in the view folder. BTW, what is the vob name in your setup? "vobs" or "gtx2"? If it is, can you specify "load /gtx2" instead of "load vobs/gtx2", and see what happens? Example with three VOBs. (vob1, vob2, vob3) Configspec: load \vob1\CM load \vob2\Source load \vob3\CM windows: local_view\vob1 local_view\vob2 local_view\vob3 linux: local_view\vobs\vob1 local_view\vobs\vob2 local_view\vobs\vob3 Is this assumption correct in linux? Anyhow, you can download the latest version from http://hudson.ramfelt.se , as it has a text field for specifying the VOB paths. In the text field you would specify "vobs/vob1 vobs/vob2". Please try it and let me know how it works out.
          esmalling Eric Smalling added a comment -

          Using "load /gtx2" gives the error:

          cleartool: Error: Unable to determine version for VOB root directory element.
          cleartool: Error: Unable to access "/gtx2": No such file or directory.
          cleartool: Error: 1 config spec load rule problems encountered.

          I downloaded your latest plugin and put "vobs/gtx2" in the new field and am
          getting the following error at build time:
          FATAL: java.lang.String.isEmpty()Z
          java.lang.NoSuchMethodError: java.lang.String.isEmpty()Z
          at hudson.plugins.clearcase.ClearToolExec.getVobNames(ClearToolExec.java:84)
          at hudson.plugins.clearcase.ClearToolExec.lshistory(ClearToolExec.java:60)
          at hudson.plugins.clearcase.ClearCaseSCM.checkout(ClearCaseSCM.java:163)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:541)
          at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:223)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:189)
          at hudson.model.Run.run(Run.java:649)
          at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:172)
          at hudson.model.ResourceController.execute(ResourceController.java:70)
          at hudson.model.Executor.run(Executor.java:62)

          esmalling Eric Smalling added a comment - Using "load /gtx2" gives the error: cleartool: Error: Unable to determine version for VOB root directory element. cleartool: Error: Unable to access "/gtx2": No such file or directory. cleartool: Error: 1 config spec load rule problems encountered. I downloaded your latest plugin and put "vobs/gtx2" in the new field and am getting the following error at build time: FATAL: java.lang.String.isEmpty()Z java.lang.NoSuchMethodError: java.lang.String.isEmpty()Z at hudson.plugins.clearcase.ClearToolExec.getVobNames(ClearToolExec.java:84) at hudson.plugins.clearcase.ClearToolExec.lshistory(ClearToolExec.java:60) at hudson.plugins.clearcase.ClearCaseSCM.checkout(ClearCaseSCM.java:163) at hudson.model.AbstractProject.checkout(AbstractProject.java:541) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:223) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:189) at hudson.model.Run.run(Run.java:649) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:172) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:62)
          redsolo redsolo added a comment -

          I was suprised to see that error, but my guess is that you are running on JDK
          1.5, right?

          I will fix it so it works with 1.5 when I get home in a couple of hours.

          redsolo redsolo added a comment - I was suprised to see that error, but my guess is that you are running on JDK 1.5, right? I will fix it so it works with 1.5 when I get home in a couple of hours.
          esmalling Eric Smalling added a comment -

          Yes - we're stuck on 1.5 here

          esmalling Eric Smalling added a comment - Yes - we're stuck on 1.5 here
          redsolo redsolo added a comment -

          Ive fixed the JDK 1.6 dependency, and I hope there are no other ones. Ive also
          triggered a new build on my hudson site, so if you please could try out the new
          version?

          redsolo redsolo added a comment - Ive fixed the JDK 1.6 dependency, and I hope there are no other ones. Ive also triggered a new build on my hudson site, so if you please could try out the new version?
          esmalling Eric Smalling added a comment -

          That seems to have fixed it.

          esmalling Eric Smalling added a comment - That seems to have fixed it.
          redsolo redsolo added a comment -

          Both issues have been fixed

          redsolo redsolo added a comment - Both issues have been fixed
          abayer Andrew Bayer added a comment -

          Bulk-updating all bugs fixed through 0.8.1 to VERIFIED. Part of cleanup for
          0.8.2 release.

          abayer Andrew Bayer added a comment - Bulk-updating all bugs fixed through 0.8.1 to VERIFIED. Part of cleanup for 0.8.2 release.

          People

            redsolo redsolo
            esmalling Eric Smalling
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: