There are a few bugs concerning DefaultBuildChooser and deleted commits: https://issues.jenkins-ci.org/browse/JENKINS-10385 https://issues.jenkins-ci.org/browse/JENKINS-10571 https://issues.jenkins-ci.org/browse/JENKINS-21980 https://issues.jenkins-ci.org/browse/JENKINS-21000
The cause is that DefaultBuildChooser picks the lastBuildRevision when there are no changes, but that revision may be deleted from the repository. There are a few common reasons for deleted commits: A branch was deleted A branch was force pushed A build creates a commit (pre build merge), but fails to push The last case can be solved by testing the lastBuildRevision, and falling back to the marked revision if needed. In the other cases I think it would be best to test if lastBuildRevision exists, and if not go to previousBuild.buildData.lastRevision (loop until no more builds). In either case, it looks like DefaultBuildChooser could use some refactoring. And there's some duplication with InverseBuildChooser. Unfortunately there aren't many tests for DefaultBuildChooser (some GitSCMTest tests do test specific cases, but that's about it). Should I just write tests for all cases I can think of based on my understanding of the current code, and go for it? It looks like there are a lot of edge cases that are easy to miss. Does my proposed fix make sense? Thoughts on DefaultBuildChooser refactoring? Thanks, Wannes -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
