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

After deleting last build, next build of last build is zombie

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      If you have a project with several builds, delete the last one, then go to the new last build (the former penultimate build) and ask for its next build, you get the now-deleted last build back! At least in the API; from the UI, you have a Next Build link which gives a 404. This is a symmetric bug from JENKINS-16194, and is caused by the abuse of selfReference to mean also "no such build".

      While reproducing this in a unit test I found another deletion-related bug: AbstractLazyLoadRunMap.numberOnDisk does not get updated when a build is deleted. The symptom is that after the deletion of the last build, say #2, the project's last build will correctly be reported as #1—but a fresh copy which is not equals to the original. The presence of two copies of the "same" build can cause mayhem.

        Attachments

          Issue Links

            Activity

            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            changelog.html
            core/src/main/java/hudson/model/AbstractBuild.java
            core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
            test/src/test/groovy/hudson/model/AbstractBuildTest.groovy
            http://jenkins-ci.org/commit/jenkins/7ca4dc47ecff4c3eb3b8041e521fc076efc42767
            Log:
            [FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble.
            JENKINS-16194 and an analogous but opposite bug fixed more simply by introducing a separate NONE constant.
            Also numberOnDisk did not get updated properly after a build was deleted, causing double loading of build records in some cases.

            Compare: https://github.com/jenkinsci/jenkins/compare/ed03fbbc9d7a...7ca4dc47ecff

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/AbstractBuild.java core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java test/src/test/groovy/hudson/model/AbstractBuildTest.groovy http://jenkins-ci.org/commit/jenkins/7ca4dc47ecff4c3eb3b8041e521fc076efc42767 Log: [FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble. JENKINS-16194 and an analogous but opposite bug fixed more simply by introducing a separate NONE constant. Also numberOnDisk did not get updated properly after a build was deleted, causing double loading of build records in some cases. Compare: https://github.com/jenkinsci/jenkins/compare/ed03fbbc9d7a...7ca4dc47ecff
            Hide
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #2929
            [FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble. (Revision 7ca4dc47ecff4c3eb3b8041e521fc076efc42767)

            Result = SUCCESS
            Jesse Glick : 7ca4dc47ecff4c3eb3b8041e521fc076efc42767
            Files :

            • core/src/main/java/hudson/model/AbstractBuild.java
            • changelog.html
            • test/src/test/groovy/hudson/model/AbstractBuildTest.groovy
            • core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2929 [FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble. (Revision 7ca4dc47ecff4c3eb3b8041e521fc076efc42767) Result = SUCCESS Jesse Glick : 7ca4dc47ecff4c3eb3b8041e521fc076efc42767 Files : core/src/main/java/hudson/model/AbstractBuild.java changelog.html test/src/test/groovy/hudson/model/AbstractBuildTest.groovy core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Jesse Glick
            Path:
            core/src/main/java/hudson/model/AbstractBuild.java
            core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
            test/src/test/groovy/hudson/model/AbstractBuildTest.groovy
            http://jenkins-ci.org/commit/jenkins/3493bfa273a3d9cc7d22354cc2dc5c8e06bb4667
            Log:
            [FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble.
            JENKINS-16194 and an analogous but opposite bug fixed more simply by introducing a separate NONE constant.
            Also numberOnDisk did not get updated properly after a build was deleted, causing double loading of build records in some cases.
            (cherry picked from commit 7ca4dc47ecff4c3eb3b8041e521fc076efc42767)

            Conflicts:
            changelog.html

            Compare: https://github.com/jenkinsci/jenkins/compare/624395829bfd...3493bfa273a3

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/model/AbstractBuild.java core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java test/src/test/groovy/hudson/model/AbstractBuildTest.groovy http://jenkins-ci.org/commit/jenkins/3493bfa273a3d9cc7d22354cc2dc5c8e06bb4667 Log: [FIXED JENKINS-19920] Using selfReference to mean “none” from nextBuild/previousBuild was just asking for trouble. JENKINS-16194 and an analogous but opposite bug fixed more simply by introducing a separate NONE constant. Also numberOnDisk did not get updated properly after a build was deleted, causing double loading of build records in some cases. (cherry picked from commit 7ca4dc47ecff4c3eb3b8041e521fc076efc42767) Conflicts: changelog.html Compare: https://github.com/jenkinsci/jenkins/compare/624395829bfd...3493bfa273a3

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                jglick Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: