|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Maybe such a problem also exists, but that is not the bug I am tracking. In the case reported to me, Run.delete evidently succeeds, but the Run is still returned from getNextBuild of its immediate predecessor a moment later, which should never happen. (getNextBuild should only return a nondeleted build, or null if this was the most recent nondeleted build.) The reported exception then follows because in the case of a Maven module set, there can be multiple builds of a given module associated with one build of the module set—the build of matching number, and then any succeeding builds up until some cutoff—and all are deleted when the module set build is deleted in the course of routine LogRotator cleanup.