Details

    • Type: Improvement
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: clearcase-plugin
    • Labels:
      None

      Description

      Using the corrent method for Change detection (lshistory) works when the config spec is based on some branch/LATEST rules, which is the correct settings for Continuous Integration.

      However for maintenance projects where the Config Spec is based on specific LABELS the lshistory is not adequate since the LATEST changes in the branch may not reflect the changes made on the config spec used since last build.

      Therefore there should be also the option to disable any change detection (disable run lshistory), unless of course you know some other way of trackign changes on builds based on Floating Labels.

        Issue Links

          Activity

          Hide
          raspy Krzysztof Malinowski added a comment -

          Can we link it as a duplicate of JENKINS-7218?

          Show
          raspy Krzysztof Malinowski added a comment - Can we link it as a duplicate of JENKINS-7218 ?
          Hide
          vlatombe Vincent Latombe added a comment -

          I would say it is related, but not a duplicate.

          Show
          vlatombe Vincent Latombe added a comment - I would say it is related, but not a duplicate.
          Hide
          raspy Krzysztof Malinowski added a comment -

          The author seems to be interested in getting changes by label tracking instead, so in this case it duplicates JENKINS-7218. As for disabling lshistory it would be sufficient to disable SCM polling if it's not adequate. Am I missing something?

          Show
          raspy Krzysztof Malinowski added a comment - The author seems to be interested in getting changes by label tracking instead, so in this case it duplicates JENKINS-7218 . As for disabling lshistory it would be sufficient to disable SCM polling if it's not adequate. Am I missing something?
          Hide
          vlatombe Vincent Latombe added a comment -

          lshistory is used for two use cases :

          • during polling to determine whether there are changes
          • during the build in order to build the changelog
          Show
          vlatombe Vincent Latombe added a comment - lshistory is used for two use cases : during polling to determine whether there are changes during the build in order to build the changelog
          Hide
          josesa Jose Sa added a comment -

          One possible solution for this would be to use the command 'cleartool find $

          {CLEARCASE_VIEWPATH}

          $

          {load_rule_line}

          -cview -print' for each load rule entry, storing the output in some file that would be used for comparison between builds (checking for differences)

          Show
          josesa Jose Sa added a comment - One possible solution for this would be to use the command 'cleartool find $ {CLEARCASE_VIEWPATH} $ {load_rule_line} -cview -print' for each load rule entry, storing the output in some file that would be used for comparison between builds (checking for differences)
          Hide
          josesa Jose Sa added a comment -

          To get the changelog it would be possible using the similar command as in lshistory for each different line (full version extended path)

          Example:
          ct desc \
          -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' \
          /Vobs/BETS/production_and_patches/windows_patch_framework/create_patch.pl@@/main/27
          "20101021.140308" "scmbuild" "/Vobs/BETS/production_and_patches/windows_patch_framework/create_patch.pl" "/main/27" "create version" "checkin"

          Show
          josesa Jose Sa added a comment - To get the changelog it would be possible using the similar command as in lshistory for each different line (full version extended path) Example: ct desc \ -fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' \ /Vobs/BETS/production_and_patches/windows_patch_framework/create_patch.pl@@/main/27 "20101021.140308" "scmbuild" "/Vobs/BETS/production_and_patches/windows_patch_framework/create_patch.pl" "/main/27" "create version" "checkin"
          Hide
          vlatombe Vincent Latombe added a comment -

          Implemented in hudson/master. Testing has mostly been done on UCM where you have 3 choices availbable (no history, current branch, branch + rebase), feel free to validate for Base.

          Show
          vlatombe Vincent Latombe added a comment - Implemented in hudson/master. Testing has mostly been done on UCM where you have 3 choices availbable (no history, current branch, branch + rebase), feel free to validate for Base.
          Hide
          josesa Jose Sa added a comment -

          After reading more of JENKINS-7218 It seems a good step in the right direction but I also would like to see changes on branch on some cases (mostly only build scripts). This covers 99% of code with it and I guess I could instate policy to have changes on the rest to also com by label.

          Having a rather complex configspec with multiple branches and labels, the best solution would be to use lshistory as you are using (because it is very fast and using the -minor option really gets everything), instead of list all versions in current view with "cleartool find $loadRule -cview -print" and comparing outputs between builds.

          I've tested this with version 1.3.5 and the log output does get a bit large some times (100Mb from a build not run over a month). I'll probably open a new Issue to better filter the output in log, to show only the relevant entries.

          The "no history" option will come in handy because I have some chained jobs in clearcase views (compilation first in Solaris chained with more compilation and packaging on windows), so in the second job it saves time doing changelog that was already done in the first job.

          Show
          josesa Jose Sa added a comment - After reading more of JENKINS-7218 It seems a good step in the right direction but I also would like to see changes on branch on some cases (mostly only build scripts). This covers 99% of code with it and I guess I could instate policy to have changes on the rest to also com by label. Having a rather complex configspec with multiple branches and labels, the best solution would be to use lshistory as you are using (because it is very fast and using the -minor option really gets everything), instead of list all versions in current view with "cleartool find $loadRule -cview -print" and comparing outputs between builds. I've tested this with version 1.3.5 and the log output does get a bit large some times (100Mb from a build not run over a month). I'll probably open a new Issue to better filter the output in log, to show only the relevant entries. The "no history" option will come in handy because I have some chained jobs in clearcase views (compilation first in Solaris chained with more compilation and packaging on windows), so in the second job it saves time doing changelog that was already done in the first job.

            People

            • Assignee:
              vlatombe Vincent Latombe
              Reporter:
              josesa Jose Sa
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: