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

user specifed view/configspec_creationscript and use of -avobs

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Trivial Trivial
    • clearcase-plugin
    • None
    • Platform: All, OS: All

      I have 3 requests for enhancement.

      +++ View creation /config creation script other than standard mkview:

      It would be nice if we could point to another script to run to generate the
      view and config spec. (Lot of businesses have created those kind of scripts)

      +++ Make $CLEARCASE_VIEW and $CLEARCASE_VIEWPATH available in load rules

      Currently I cannot use the options $CLEARCASE_VIEW and $CLEARCASE_VIEWPATH in
      the load rules or vob path.
      I found no other way to do lshistory then to add a view centric path. Currently
      I need to hard code the view name. Would like to use the standard parameter.

      This feature and the next one are mutual exclusive. If you implement one, the
      need for the other goes away or is lessened. I personally prefer the -avobs
      solution.

      +++ option to export $CLEARCASE_AVOBS and have lshistory use -avobs instead of -
      all
      In dynamic views you can specify a $CLEARCASE_AVOBS variable to group a set of
      vobs to search in (usefull in a site with 800+ vobs)
      Would be nice if $CLEARCASE_AVOBS is set or specified, lshistory would use -
      avobs instead of -all

          [JENKINS-4447] user specifed view/configspec_creationscript and use of -avobs

          Andrew Bayer added a comment -

          I think you may be best off forking the plugin and implementing the
          functionality you want there - I don't think I'll be adding any of this to the
          main ClearCase plugin in the near future.

          I'm still confused about the second/third request - this, obviously, relates to
          issue 4222. Why do you need "/view/my_viewname/vobs/xpuModule" instead of
          "/vobs/xpuModule"?

          Andrew Bayer added a comment - I think you may be best off forking the plugin and implementing the functionality you want there - I don't think I'll be adding any of this to the main ClearCase plugin in the near future. I'm still confused about the second/third request - this, obviously, relates to issue 4222. Why do you need "/view/my_viewname/vobs/xpuModule" instead of "/vobs/xpuModule"?

          frankst added a comment -

          I can test it in version 1.02 later, but specifying
          just /vobs/oam , /vobs/fcl , ... in "vobs path" in plugin version 0.91 gives me
          this result:

          [ngrbs_iser2.1] $ /usr/atria/bin/cleartool lshistory r -since 11-sep
          09.19:35:57utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -
          branch brtype:i_iser -nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec
          cleartool: Error: Unable to access "/vobs/oam": ClearCase object not found.
          cleartool: Error: Unable to access "/vobs/fcl": ClearCase object not found.
          cleartool: Error: Unable to access "/vobs/dataplane": ClearCase object not
          found.
          cleartool: Error: Unable to access "/vobs/ipsec": ClearCase object not found.
          FATAL: Base ClearCase failed. exit code=1
          FATAL: cleartool did not return the expected exit code. Command
          line="lshistory -r -since 11-sep-09.19:35:57utc+0000 -fmt \"%Nd\" \"%u\" \"%
          En\" \"%Vn\" \"%e\" \"%o\" \n%c\n -branch brtype:i_iser -
          nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec", actual exit code=1
          java.io.IOException: cleartool did not return the expected exit code. Command
          line="lshistory -r -since 11-sep-09.19:35:57utc+0000 -fmt \"%Nd\" \"%u\" \"%
          En\" \"%Vn\" \"%e\" \"%o\" \n%c\n -branch brtype:i_iser -
          nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec", actual exit code=1
          at hudson.plugins.clearcase.HudsonClearToolLauncher.run
          (HudsonClearToolLauncher.java:100)
          at hudson.plugins.clearcase.ClearToolExec.lshistory
          (ClearToolExec.java:90)
          at hudson.plugins.clearcase.history.AbstractHistoryAction.runLsHistory
          (AbstractHistoryAction.java:81)
          at hudson.plugins.clearcase.history.AbstractHistoryAction.getChanges
          (AbstractHistoryAction.java:67)
          at hudson.plugins.clearcase.AbstractClearCaseScm.checkout
          (AbstractClearCaseScm.java:296)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:898)
          at hudson.model.AbstractBuild$AbstractRunner.checkout
          (AbstractBuild.java:400)
          at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349)
          at hudson.model.Run.run(Run.java:1106)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:93)
          at hudson.model.Executor.run(Executor.java:122)

          frankst added a comment - I can test it in version 1.02 later, but specifying just /vobs/oam , /vobs/fcl , ... in "vobs path" in plugin version 0.91 gives me this result: [ngrbs_iser2.1] $ /usr/atria/bin/cleartool lshistory r -since 11-sep 09.19:35:57utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' - branch brtype:i_iser -nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec cleartool: Error: Unable to access "/vobs/oam": ClearCase object not found. cleartool: Error: Unable to access "/vobs/fcl": ClearCase object not found. cleartool: Error: Unable to access "/vobs/dataplane": ClearCase object not found. cleartool: Error: Unable to access "/vobs/ipsec": ClearCase object not found. FATAL: Base ClearCase failed. exit code=1 FATAL: cleartool did not return the expected exit code. Command line="lshistory -r -since 11-sep-09.19:35:57utc+0000 -fmt \"%Nd\" \"%u\" \"% En\" \"%Vn\" \"%e\" \"%o\" \n%c\n -branch brtype:i_iser - nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec", actual exit code=1 java.io.IOException: cleartool did not return the expected exit code. Command line="lshistory -r -since 11-sep-09.19:35:57utc+0000 -fmt \"%Nd\" \"%u\" \"% En\" \"%Vn\" \"%e\" \"%o\" \n%c\n -branch brtype:i_iser - nco /vobs/oam /vobs/fcl /vobs/dataplane /vobs/ipsec", actual exit code=1 at hudson.plugins.clearcase.HudsonClearToolLauncher.run (HudsonClearToolLauncher.java:100) at hudson.plugins.clearcase.ClearToolExec.lshistory (ClearToolExec.java:90) at hudson.plugins.clearcase.history.AbstractHistoryAction.runLsHistory (AbstractHistoryAction.java:81) at hudson.plugins.clearcase.history.AbstractHistoryAction.getChanges (AbstractHistoryAction.java:67) at hudson.plugins.clearcase.AbstractClearCaseScm.checkout (AbstractClearCaseScm.java:296) at hudson.model.AbstractProject.checkout(AbstractProject.java:898) at hudson.model.AbstractBuild$AbstractRunner.checkout (AbstractBuild.java:400) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349) at hudson.model.Run.run(Run.java:1106) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:122)

          frankst added a comment -

          The same test with plugin 0.91: now specifying view centric path works:

          [ngrbs_iser2.1] $ /usr/atria/bin/cleartool lshistory r -since 11-sep
          09.23:18:45utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' -
          branch brtype:i_iser -
          nco /view/ngrbs_iser2.1/vobs/oam /view/ngrbs_iser2.1/vobs/fcl
          [workspace] $ /bin/sh xe /usr/local/apache-tomcat
          6.0.18/temp/hudson8232978384152728254.sh

          frankst added a comment - The same test with plugin 0.91: now specifying view centric path works: [ngrbs_iser2.1] $ /usr/atria/bin/cleartool lshistory r -since 11-sep 09.23:18:45utc+0000 -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' - branch brtype:i_iser - nco /view/ngrbs_iser2.1/vobs/oam /view/ngrbs_iser2.1/vobs/fcl [workspace] $ /bin/sh xe /usr/local/apache-tomcat 6.0.18/temp/hudson8232978384152728254.sh

          Andrew Bayer added a comment -

          Yeah, that's behavior that changed from 0.9 to 1.0 - while changing to lshistory
          -all, I standardized how all the various view types (base/UCM, snapshot/dynamic)
          determined the paths to pass to lshistory, and started requiring "load rules"
          for all view types as well. Now you can use "/vobs/some_vob", "vobs/some_vob",
          "load /vobs/some_vob", or "load vobs/some_vob" (the latter two to deal with the
          fact that using the term "load rules" makes it seem like you may need "load ",
          and I decided it was easier to just tear it out if it showed up than to find a
          clear enough wording to explain it), and any of them will result in "cleartool
          lshistory -all -since (blah) -fmt (blah) vobs/some_vob", run from the view
          directory.

          Andrew Bayer added a comment - Yeah, that's behavior that changed from 0.9 to 1.0 - while changing to lshistory -all, I standardized how all the various view types (base/UCM, snapshot/dynamic) determined the paths to pass to lshistory, and started requiring "load rules" for all view types as well. Now you can use "/vobs/some_vob", "vobs/some_vob", "load /vobs/some_vob", or "load vobs/some_vob" (the latter two to deal with the fact that using the term "load rules" makes it seem like you may need "load ", and I decided it was easier to just tear it out if it showed up than to find a clear enough wording to explain it), and any of them will result in "cleartool lshistory -all -since (blah) -fmt (blah) vobs/some_vob", run from the view directory.

          Andrew Bayer added a comment -

          And I guess I could look into parsing out the "/view/my_viewname" the same way I
          do "load ", but it seems superfluous, since you really can just specify
          "/vobs/some_vob" in 1.0 and later. =)

          Andrew Bayer added a comment - And I guess I could look into parsing out the "/view/my_viewname" the same way I do "load ", but it seems superfluous, since you really can just specify "/vobs/some_vob" in 1.0 and later. =)

          frankst added a comment -

          I think just specifying /vobs/oam, ... will work if you execute the lshistory
          within a setview command, e.g.

          cleartool setview -exec 'cleartool lshistory -all .... ' $CLEARCASE_VIEWNAME

          In the log I see it executes a cleartool startview which will only mount the
          view to /view. And it makes total sense for snapshot views, but not as much for
          dynamic views.

          I am confused in what directory it executes that lshistory command. If it is
          the workspace that would not work since i don't have any sources there.
          If it executes that command in /view/my_viewname then it should work in version
          1.0 as you state.

          Will test it in another installation I have.

          frankst added a comment - I think just specifying /vobs/oam, ... will work if you execute the lshistory within a setview command, e.g. cleartool setview -exec 'cleartool lshistory -all .... ' $CLEARCASE_VIEWNAME In the log I see it executes a cleartool startview which will only mount the view to /view. And it makes total sense for snapshot views, but not as much for dynamic views. I am confused in what directory it executes that lshistory command. If it is the workspace that would not work since i don't have any sources there. If it executes that command in /view/my_viewname then it should work in version 1.0 as you state. Will test it in another installation I have.

          Andrew Bayer added a comment -

          It executes in a different place depending on the view type:

          • for snapshot: (workspace)/view_name
          • for dynamic: (view drive)/view_name

          Basically, no matter what, it's running from the root of the actual view.

          Andrew Bayer added a comment - It executes in a different place depending on the view type: for snapshot: (workspace)/view_name for dynamic: (view drive)/view_name Basically, no matter what, it's running from the root of the actual view.

          frankst added a comment -

          Ok, I tested it on hudson ver 1.316 with clearcase plugin 1.02 and it works !!!
          So you must be correct that the view centric path was breaking it.

          Thanks a lot for your help. Can we document this for other idiots like me?

          frankst added a comment - Ok, I tested it on hudson ver 1.316 with clearcase plugin 1.02 and it works !!! So you must be correct that the view centric path was breaking it. Thanks a lot for your help. Can we document this for other idiots like me?

          Andrew Bayer added a comment -

          Ah, documentation, my great nemesis! =)

          I'll make a run at updating the wiki docs now. I'm also going to recategorize
          this as a P5 enhancement, just for bookkeeping purposes. If you'd like to make a
          run at implementing the script-as-view/config-spec-creation functionality, feel
          free - if it can be done in a clean enough way, I'm willing to consider adding
          it to a future release.

          Andrew Bayer added a comment - Ah, documentation, my great nemesis! =) I'll make a run at updating the wiki docs now. I'm also going to recategorize this as a P5 enhancement, just for bookkeeping purposes. If you'd like to make a run at implementing the script-as-view/config-spec-creation functionality, feel free - if it can be done in a clean enough way, I'm willing to consider adding it to a future release.

          frankst added a comment -

          You are assuming I have any skills in creating plugins
          Will have to do some reading on that first.

          I agree with postponing the view creation logic.
          Thanks again. Will upgrade again to 1.02.

          frankst added a comment - You are assuming I have any skills in creating plugins Will have to do some reading on that first. I agree with postponing the view creation logic. Thanks again. Will upgrade again to 1.02.

            Unassigned Unassigned
            frankst frankst
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: