Building a better catch-up system

[Jo Shields]

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

[Jo Shields]

https://github.com/directhex/jenkins-git-catch-up

/micdrop

When I'm done, it'll optionally allow for merges to be squashed (i.e. if someone merges a large branch, that merge commit will be regarded as one commit, not as potentially dozens)