I'm trying to resolve the nearly-a-decade-old bug to allow Jenkins to do one build per commit, without dirty workarounds in dispatcher jobs. Currently, it'll bundle together multiple commits received at once - for example, a user does "git push" to send more than one commit.
I've written a custom BuildChooser for the git plugin, which correctly determines a list of commits to build, between the last known build and HEAD (DefaultBuildChooser basically determines the commitid of HEAD and passes that down in a single-entry array). GitSCM.java already contains some code to handle cases where more than one "candidate" is received, but I don't quite understand what it's intending to do - it sets the current build revision to the first entry in the array ( https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L918-924) then immediately schedules another build of the same job without any context whatsoever ( https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L934-935 ) Is there really nowherere in the API to do project.scheduleBuild(arbitraryBuildObject) or equivalent, to make actual use of the candidates array i've already generated? The current behaviour seems terribly racy (behaviour seems to vary depending on how quickly I step through breakpoints, and the size of the array). At best, right now I have it sometimes (but not always) building last-known-revision..HEAD~1 as the current job then scheduling HEAD as the next job -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CACyRP70wxCVUHNKQxk0UZnKcLnu-1Y0D416a5TxrNQbonBDsgA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
