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

Provide option to run lshistory inside loadrule

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • clearcase-plugin
    • None
    • Platform: All, OS: All

      when lshistory is run the filepaths returned are relative to where the command
      is run from. Currently we run lshistory from the viewroot.

      This results in the loadrule(s) being prefixed each changed file e.g. if the
      load rule is vobs/MyClient/MyProject all files will look like
      /vobs/Myclient/MyProject/MyComponent/src/main/java/etc...

      Suggest we provide a option to run lshistory inside each loadrule so to avoid
      long prefixes. In the above case the files would then look like

      MyComponent/src/main/java/etc..

          [JENKINS-1713] Provide option to run lshistory inside loadrule

          tonychan added a comment -

          Related to this is that the current clearcase plugin (0.6) grabs the changeset
          for the entire view, regardless of load options because lshistory is ran in the
          view root.

          For example, the particular view may contain packages A, B and C. A Hudson job
          is configured with a config spec to load A/ and and another Hudson job is
          configured to load B/ but when the CC plugin calls lshistory, it will grab the
          changeset for the entire view: A, B and C. This distorts the change set
          history/SCM change polling and the email notifications that only mail to
          contributors.

          In essence, the CC plugin should be enhanced to run lshistory so that it only
          shows the change sets for the configured loaded directories.

          tonychan added a comment - Related to this is that the current clearcase plugin (0.6) grabs the changeset for the entire view, regardless of load options because lshistory is ran in the view root. For example, the particular view may contain packages A, B and C. A Hudson job is configured with a config spec to load A/ and and another Hudson job is configured to load B/ but when the CC plugin calls lshistory, it will grab the changeset for the entire view: A, B and C. This distorts the change set history/SCM change polling and the email notifications that only mail to contributors. In essence, the CC plugin should be enhanced to run lshistory so that it only shows the change sets for the configured loaded directories.

          redsolo added a comment -

          Thanks for your comments, about "In essence, the CC plugin should be enhanced to
          run lshistory so that it only shows the change sets for the configured loaded
          directories."

          That is preferred, but Im not sure on how to do it. Should the lshistory be
          executed in every load rule path? I guess, if there only is 1 or 2 load rules,
          that would not be a problem; but several then it will take much longer.

          Is there any other way to only get history for a certain stream and load rule?

          redsolo added a comment - Thanks for your comments, about "In essence, the CC plugin should be enhanced to run lshistory so that it only shows the change sets for the configured loaded directories." That is preferred, but Im not sure on how to do it. Should the lshistory be executed in every load rule path? I guess, if there only is 1 or 2 load rules, that would not be a problem; but several then it will take much longer. Is there any other way to only get history for a certain stream and load rule?

          tonychan added a comment -

          Our CC admin suggested this:

          cleartool find . -type f -exec "cleartool lshistory -branch <branch> -last
          %CLEARCASE_XPN%"

          Which should achieve the same effect, though I'm not sure what the performance
          effects are of using this approach.

          tonychan added a comment - Our CC admin suggested this: cleartool find . -type f -exec "cleartool lshistory -branch <branch> -last %CLEARCASE_XPN%" Which should achieve the same effect, though I'm not sure what the performance effects are of using this approach.

          tonychan added a comment -

          Any updates or plans to accommodate for this feature request?

          tonychan added a comment - Any updates or plans to accommodate for this feature request?

          janwe added a comment -

          Implementing this option may also solve an issue with polling not detecting new
          files in the root of a load rule after a deliver (see issue 2405).

          Is it common to have lots of load rules in a view? In our configuration we have
          max 2 so issuing a lshistory for each of them will not cause too much of a
          performance hit I think.

          Regarding the suggestion to use the "cleartool find..." command: We previously
          used CruiseControl and I poked around their ClearCase code to see how they did
          change polling. I noticed a huge comment saying that they had to move away from
          "cleartool find..." because it took way to long... so they ended up with almost
          exactly the same command as Hudson ClearCase plugin currently uses.

          janwe added a comment - Implementing this option may also solve an issue with polling not detecting new files in the root of a load rule after a deliver (see issue 2405). Is it common to have lots of load rules in a view? In our configuration we have max 2 so issuing a lshistory for each of them will not cause too much of a performance hit I think. Regarding the suggestion to use the "cleartool find..." command: We previously used CruiseControl and I poked around their ClearCase code to see how they did change polling. I noticed a huge comment saying that they had to move away from "cleartool find..." because it took way to long... so they ended up with almost exactly the same command as Hudson ClearCase plugin currently uses.

          Andrew Bayer added a comment -

          Reassigning to me.

          Andrew Bayer added a comment - Reassigning to me.

          Andrew Bayer added a comment -

          I believe this is actually mostly resolved already - the lshistory -r is run
          against the provided VOB paths for non-UCM views and against the load rules for
          UCM views, not the view as a whole. That doesn't quite deal with issue 2405, but
          the work I'm doing on https://hudson.dev.java.net/issues/show_bug.cgi?id=3211
          will eventually resolve that one.

          Andrew Bayer added a comment - I believe this is actually mostly resolved already - the lshistory -r is run against the provided VOB paths for non-UCM views and against the load rules for UCM views, not the view as a whole. That doesn't quite deal with issue 2405, but the work I'm doing on https://hudson.dev.java.net/issues/show_bug.cgi?id=3211 will eventually resolve that one.

          Andrew Bayer added a comment -

          Marking as verified, fixed in 0.8.2.

          Andrew Bayer added a comment - Marking as verified, fixed in 0.8.2.

          yrogovaya added a comment - - edited

          I'm using version 1.1.1.

          Looks like there's no way to make lshistory run for a loadrule.

          yrogovaya added a comment - - edited I'm using version 1.1.1. Looks like there's no way to make lshistory run for a loadrule.

            abayer Andrew Bayer
            lynggaard lynggaard
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: