-
Bug
-
Resolution: Fixed
-
Major
-
1.509.3 or trunk
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.
- is related to
-
JENKINS-16194 Delete the oldest build but it still come up on HistoryWidget
-
- Resolved
-
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-16194and 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