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

Disable lshistory

    XMLWordPrintable

Details

    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.

      Attachments

        Issue Links

          Activity

            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)

            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)
            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"

            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"

            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.

            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.
            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.

            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.
            stuartrowe Stuart Rowe added a comment -

            Sorry, not sure how I managed to assign this to myself.

            stuartrowe Stuart Rowe added a comment - Sorry, not sure how I managed to assign this to myself.

            People

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

              Dates

                Created:
                Updated:
                Resolved: