• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Critical Critical
    • clearcase-plugin
    • None

      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.

          [JENKINS-7122] Disable lshistory

          Jose Sa created issue -
          Jose Sa made changes -
          Description Original: Using the correct method for Change detection 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.
          New: 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.

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

          Krzysztof Malinowski added a comment - Can we link it as a duplicate of JENKINS-7218 ?

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

          Vincent Latombe added a comment - I would say it is related, but not a duplicate.

          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?

          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?

          lshistory is used for two use cases :

          • during polling to determine whether there are changes
          • during the build in order to build the changelog

          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

          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)

          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)

          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"

          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"

          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.

          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.
          Vincent Latombe made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

            vlatombe Vincent Latombe
            josesa Jose Sa
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: