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

Prune stale branches prevents git plugin change history display

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      git plugin 2.3.6 pre-release (pre-release for git 2.4.0)
      git client plugin 1.18.0 pre-release
    • Similar Issues:

      Description

      A git SCM based job will stop showing changes (both "Recent Changes" and "Changes") if "Prune stale remote-tracking branches" is enabled. It will resume showing changes if the "Prune stake remote-tracking branches is removed from the job definition.

      It appears that a new method "purgeStaleBranches" was added to the git plugin in March 2015 . It is purging a branch named "refs/remotes/origin/master" even though that is the only branch defined in the job.

      To duplicate the problem:

      1. Start Jenkins
      2. Install pre-release git client plugin
      3. Install pre-release git plugin
      4. Configure a new job with Git SCM as source control
      5. Configure the job to poll SCM frequently (once a minute)
      6. Run the job once, confirm no history is shown
      7. Commit a change to the repository that job is tracking
      8. Wait for polling to detect the change, confirm history is shown
      9. Reconfigure job to add "Prune stale remote-tracking branches"
      10. Commit a change to the repository that job is tracking
      11. Wait for polling to detect the change, confirm history is shown
      12. Commit another change to the repository that job is tracking
      13. Wait for polling to detect the change, confirm history is NOT shown

      Once history is not being shown, it will continue to not be shown, even though the polling log and the build status page shows that the job was started by an SCM change.

      If the "Prune stale remote-tracking branches" setting is removed, then two builds later the job will begin showing history again.

        Attachments

        1. Selection_042.png
          Selection_042.png
          45 kB
        2. Selection_043.png
          Selection_043.png
          86 kB
        3. Selection_044.png
          Selection_044.png
          48 kB
        4. Selection_045.png
          Selection_045.png
          15 kB
        5. Selection_046.png
          Selection_046.png
          22 kB

          Issue Links

            Activity

            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Mark Waite
            Path:
            src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java
            src/main/java/hudson/plugins/git/util/BuildData.java
            http://jenkins-ci.org/commit/git-plugin/be1890377a4623be9483e6b70df22cd8da2f7616
            Log:
            [Fix JENKINS-29482] Don't hide build history when prune stale branches is on

            Reverts "prune deleted branches from BuildData to avoid growing memory consumption"

            This reverts the bulk of commit 163e60fccd5a08199efd7d85b0b351c6e950c2f7.
            The two test cases which were added are still retained, though it is odd
            that they are unaffected by reverting the change to the production code.
            As far as I can tell, the BuildData.purgeStaleBranches method was not
            called by any test, even though it seems it should have been called.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java src/main/java/hudson/plugins/git/util/BuildData.java http://jenkins-ci.org/commit/git-plugin/be1890377a4623be9483e6b70df22cd8da2f7616 Log: [Fix JENKINS-29482] Don't hide build history when prune stale branches is on Reverts "prune deleted branches from BuildData to avoid growing memory consumption" This reverts the bulk of commit 163e60fccd5a08199efd7d85b0b351c6e950c2f7. The two test cases which were added are still retained, though it is odd that they are unaffected by reverting the change to the production code. As far as I can tell, the BuildData.purgeStaleBranches method was not called by any test, even though it seems it should have been called.
            Hide
            markewaite Mark Waite added a comment -

            Fix included in git plugin 2.4.0 released 18 July 2015

            Show
            markewaite Mark Waite added a comment - Fix included in git plugin 2.4.0 released 18 July 2015
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Nicolas De Loof
            Path:
            src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java
            src/main/java/hudson/plugins/git/util/BuildData.java
            http://jenkins-ci.org/commit/git-plugin/c1872d038cc2f584bafbc375744deb54a1dbe316
            Log:
            [Fix JENKINS-29482] remove branches in BuildData history which doesn’t exist on remote repo (anymore)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java src/main/java/hudson/plugins/git/util/BuildData.java http://jenkins-ci.org/commit/git-plugin/c1872d038cc2f584bafbc375744deb54a1dbe316 Log: [Fix JENKINS-29482] remove branches in BuildData history which doesn’t exist on remote repo (anymore)
            Hide
            rbaradari Ramin Baradari added a comment -

            Broken again in git plugin 2.4.1, git client plugin 1.19.1.

            The reproduction steps are the same as in the original bug description.

            Apparently, the GIT_PREVIOUS_COMMIT is always empty after the first build with eabled pruning and hence no change log is computed further on.

            Following are the logs of three consecutive builds. The pruning feature was enabled after the first build.

            Commit without pruning
             > git.exe rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from the remote Git repository
             > git.exe config remote.origin.url http://localhost:9090/gitblit/r/sandbox/playground.git # timeout=10
            Fetching upstream changes from http://localhost:9090/gitblit/r/sandbox/playground.git
             > git.exe --version # timeout=10
             > git.exe -c core.askpass=true fetch --tags --progress http://localhost:9090/gitblit/r/sandbox/playground.git +refs/heads/*:refs/remotes/origin/*
             > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
             > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
            Checking out Revision 8702e88ffe677c945897e3abfb365427ec7f72ce (refs/remotes/origin/master)
             > git.exe config core.sparsecheckout # timeout=10
             > git.exe checkout -f 8702e88ffe677c945897e3abfb365427ec7f72ce
             > git.exe rev-list 74d735418e3965032dd68103d02d5041589dd49b # timeout=10
            
            First commit with pruning
             > git.exe rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from the remote Git repository
             > git.exe config remote.origin.url http://localhost:9090/gitblit/r/sandbox/playground.git # timeout=10
            Pruning obsolete local branches
            Fetching upstream changes from http://localhost:9090/gitblit/r/sandbox/playground.git
             > git.exe --version # timeout=10
             > git.exe -c core.askpass=true fetch --tags --progress http://localhost:9090/gitblit/r/sandbox/playground.git +refs/heads/*:refs/remotes/origin/* --prune
             > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
             > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
            Checking out Revision f1f6a7a48503f17ce61c72d62e8d3c89a150790d (refs/remotes/origin/master)
             > git.exe config core.sparsecheckout # timeout=10
             > git.exe checkout -f f1f6a7a48503f17ce61c72d62e8d3c89a150790d
             > git.exe rev-list 8702e88ffe677c945897e3abfb365427ec7f72ce # timeout=10
             > git.exe branch -a # timeout=10
             > git.exe rev-parse "remotes/origin/master^{commit}" # timeout=10
            
            Second commit with pruning
              > git.exe rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from the remote Git repository
             > git.exe config remote.origin.url http://localhost:9090/gitblit/r/sandbox/playground.git # timeout=10
            Pruning obsolete local branches
            Fetching upstream changes from http://localhost:9090/gitblit/r/sandbox/playground.git
             > git.exe --version # timeout=10
             > git.exe -c core.askpass=true fetch --tags --progress http://localhost:9090/gitblit/r/sandbox/playground.git +refs/heads/*:refs/remotes/origin/* --prune
             > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
             > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
            Checking out Revision 61acc139dcbd11c40f8eb31d1c9be88cb02b2de8 (refs/remotes/origin/master)
             > git.exe config core.sparsecheckout # timeout=10
             > git.exe checkout -f 61acc139dcbd11c40f8eb31d1c9be88cb02b2de8
            First time build. Skipping changelog.
             > git.exe branch -a # timeout=10
             > git.exe rev-parse "remotes/origin/master^{commit}" # timeout=10
            
            Show
            rbaradari Ramin Baradari added a comment - Broken again in git plugin 2.4.1, git client plugin 1.19.1. The reproduction steps are the same as in the original bug description. Apparently, the GIT_PREVIOUS_COMMIT is always empty after the first build with eabled pruning and hence no change log is computed further on. Following are the logs of three consecutive builds. The pruning feature was enabled after the first build. Commit without pruning > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git.exe config remote.origin.url http: //localhost:9090/gitblit/r/sandbox/playground.git # timeout=10 Fetching upstream changes from http: //localhost:9090/gitblit/r/sandbox/playground.git > git.exe --version # timeout=10 > git.exe -c core.askpass= true fetch --tags --progress http: //localhost:9090/gitblit/r/sandbox/playground.git +refs/heads/*:refs/remotes/origin/* > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10 > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10 Checking out Revision 8702e88ffe677c945897e3abfb365427ec7f72ce (refs/remotes/origin/master) > git.exe config core.sparsecheckout # timeout=10 > git.exe checkout -f 8702e88ffe677c945897e3abfb365427ec7f72ce > git.exe rev-list 74d735418e3965032dd68103d02d5041589dd49b # timeout=10 First commit with pruning > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git.exe config remote.origin.url http: //localhost:9090/gitblit/r/sandbox/playground.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from http: //localhost:9090/gitblit/r/sandbox/playground.git > git.exe --version # timeout=10 > git.exe -c core.askpass= true fetch --tags --progress http: //localhost:9090/gitblit/r/sandbox/playground.git +refs/heads/*:refs/remotes/origin/* --prune > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10 > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10 Checking out Revision f1f6a7a48503f17ce61c72d62e8d3c89a150790d (refs/remotes/origin/master) > git.exe config core.sparsecheckout # timeout=10 > git.exe checkout -f f1f6a7a48503f17ce61c72d62e8d3c89a150790d > git.exe rev-list 8702e88ffe677c945897e3abfb365427ec7f72ce # timeout=10 > git.exe branch -a # timeout=10 > git.exe rev-parse "remotes/origin/master^{commit}" # timeout=10 Second commit with pruning > git.exe rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git.exe config remote.origin.url http: //localhost:9090/gitblit/r/sandbox/playground.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from http: //localhost:9090/gitblit/r/sandbox/playground.git > git.exe --version # timeout=10 > git.exe -c core.askpass= true fetch --tags --progress http: //localhost:9090/gitblit/r/sandbox/playground.git +refs/heads/*:refs/remotes/origin/* --prune > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10 > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10 Checking out Revision 61acc139dcbd11c40f8eb31d1c9be88cb02b2de8 (refs/remotes/origin/master) > git.exe config core.sparsecheckout # timeout=10 > git.exe checkout -f 61acc139dcbd11c40f8eb31d1c9be88cb02b2de8 First time build. Skipping changelog. > git.exe branch -a # timeout=10 > git.exe rev-parse "remotes/origin/master^{commit}" # timeout=10
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Mark Waite
            Path:
            src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java
            src/main/java/hudson/plugins/git/util/BuildData.java
            http://jenkins-ci.org/commit/git-plugin/336c1787c7b967e4220c4d459092397fda29892a
            Log:
            [Fix JENKINS-29482] Don't prune stale branches from BuildData

            This reverts commit c1872d038cc2f584bafbc375744deb54a1dbe316.

            Git plugin 2.4.1 included c1872d0 which regressed the plugin and
            introduced JENKINS-32218

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java src/main/java/hudson/plugins/git/util/BuildData.java http://jenkins-ci.org/commit/git-plugin/336c1787c7b967e4220c4d459092397fda29892a Log: [Fix JENKINS-29482] Don't prune stale branches from BuildData This reverts commit c1872d038cc2f584bafbc375744deb54a1dbe316. Git plugin 2.4.1 included c1872d0 which regressed the plugin and introduced JENKINS-32218
            Hide
            markewaite Mark Waite added a comment -

            Fixed in git plugin 2.4.2 - released 2 Feb 2016

            Show
            markewaite Mark Waite added a comment - Fixed in git plugin 2.4.2 - released 2 Feb 2016
            Hide
            vikulin Vadym Vikulin added a comment -

            Reproduced on git plugin 2.4.2. See screenshot.

            Show
            vikulin Vadym Vikulin added a comment - Reproduced on git plugin 2.4.2. See screenshot.
            Hide
            markewaite Mark Waite added a comment -

            Vadym Vikulin, your screen shots show that you can't be seeing this bug, because you have not enabled "Prune stale branches" in the git plugin "Additional Behaviours" section. You may have found another case where history is not shown, but the case you're reporting can't be related to "Prune stale branches", unless your screen shots somehow do not match how you've configured the job.

            If you're not seeing history, please submit a new bug report with a detailed, numbered list of the steps you take to duplicate the problem. Reopening an existing bug confuses things, since you seem to have reopened this bug report without realizing that the detailed steps included in the report do not match your steps. Refer to step 9, ""Reconfigure the job to prune stale remote tracking branches", which seems to not be used in your screen shots.

            I'm closing this bug again, assuming you'll submit a new bug.

            Show
            markewaite Mark Waite added a comment - Vadym Vikulin , your screen shots show that you can't be seeing this bug, because you have not enabled "Prune stale branches" in the git plugin "Additional Behaviours" section. You may have found another case where history is not shown, but the case you're reporting can't be related to "Prune stale branches", unless your screen shots somehow do not match how you've configured the job. If you're not seeing history, please submit a new bug report with a detailed, numbered list of the steps you take to duplicate the problem. Reopening an existing bug confuses things, since you seem to have reopened this bug report without realizing that the detailed steps included in the report do not match your steps. Refer to step 9, ""Reconfigure the job to prune stale remote tracking branches", which seems to not be used in your screen shots. I'm closing this bug again, assuming you'll submit a new bug.
            Hide
            vikulin Vadym Vikulin added a comment -

            Mark Waite, I enabled "Prune stale branches" and still no history appears.

            Show
            vikulin Vadym Vikulin added a comment - Mark Waite , I enabled "Prune stale branches" and still no history appears.
            Hide
            markewaite Mark Waite added a comment -

            Vadym Vikulin, I can't duplicate the problem you're reporting. I tried several different variants based on guesses from the screenshots you included. All of them correctly showed recent changes.

            Steps I took to try to duplicate the problem included:

            1. Define a new freestyle project named "JENKINS-29482-parameterized-checkout-subdir-blocks-history"
            2. Parameterize the build, with a "Choice" parameter named "BRANCH". Assign the first value (default) as "JENKINS-29482" and other values based on branches in the source repository (I also tried a git parameter using the git parameter plugin with the same results)
            3. Use git as the source control, with repository URL https://github.com/MarkEWaite/JENKINS-26197.git
            4. Use "*/$BRANCH" as the "Branch to build"
            5. Add "$BRANCH/src" as the "Local subdirectory for repo" for the additional behaviour "Checkout to a sub-directory"
            6. Add "Clean before checkout" as an additional behaviour
            7. Add "Prune stale remote tracking branches" as an additional behaviour
            8. Enable "Poll SCM" (schedule is optional, since I have the "Poll Now" plugin available on my Jenkins)
            9. Save the job and click the "Poll Now" link to poll for changes

            Once the job definition has been saved and run once, then I submit changes to that repository and click "Poll Now". The changes are detected by polling, the job is built, and the "Recent Changes" show the expected values. Each time I submit changes to the repository and then poll, the job runs and changes are correctly shown in the "Recent Changes" page. If there were no changes since the last build, no changes are shown in the "Recent Changes" page.

            Please provide step by step instructions that duplicate the bug.

            Show
            markewaite Mark Waite added a comment - Vadym Vikulin , I can't duplicate the problem you're reporting. I tried several different variants based on guesses from the screenshots you included. All of them correctly showed recent changes. Steps I took to try to duplicate the problem included: Define a new freestyle project named " JENKINS-29482 -parameterized-checkout-subdir-blocks-history" Parameterize the build, with a "Choice" parameter named "BRANCH". Assign the first value (default) as " JENKINS-29482 " and other values based on branches in the source repository (I also tried a git parameter using the git parameter plugin with the same results) Use git as the source control, with repository URL https://github.com/MarkEWaite/JENKINS-26197.git Use "*/$BRANCH" as the "Branch to build" Add "$BRANCH/src" as the "Local subdirectory for repo" for the additional behaviour "Checkout to a sub-directory" Add "Clean before checkout" as an additional behaviour Add "Prune stale remote tracking branches" as an additional behaviour Enable "Poll SCM" (schedule is optional, since I have the "Poll Now" plugin available on my Jenkins) Save the job and click the "Poll Now" link to poll for changes Once the job definition has been saved and run once, then I submit changes to that repository and click "Poll Now". The changes are detected by polling, the job is built, and the "Recent Changes" show the expected values. Each time I submit changes to the repository and then poll, the job runs and changes are correctly shown in the "Recent Changes" page. If there were no changes since the last build, no changes are shown in the "Recent Changes" page. Please provide step by step instructions that duplicate the bug.
            Hide
            vikulin Vadym Vikulin added a comment -

            I have no idea why but the history has started appearing. Closing the defect.

            Show
            vikulin Vadym Vikulin added a comment - I have no idea why but the history has started appearing. Closing the defect.

              People

              • Assignee:
                markewaite Mark Waite
                Reporter:
                markewaite Mark Waite
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: