I thought I remembered a pull request submitted to the git plugin to allow user definition of the comparison base. In your case, there is a "base branch" against which you want all comparisons, no matter the results of the last job. Unfortunately, I didn't find it in the current pull requests for the git plugin, though I thought it was there. Others may be able to find it and consider if it should be merged. If you can locate that pull request, you could consider building an experimental version of the git plugin with that change included, then could report the results of your testing back to the pull request.
Can't you obtain the results you want (on your different, but related concern) by asking your developers to push a new branch for changes which are to be built independently, rather than pushing to an existing branch? I believe that when pushes are detected to a new branch, a new build is queued. If multiple pushes to an existing branch are detected, they are all batched together into a single job. Mark Waite On Tue, Jul 22, 2014 at 12:28 PM, Jim Lloyd <jim.ll...@gmail.com> wrote: > Our workflow using git is similar to the GitFlow > <http://datasift.github.io/gitflow/IntroducingGitFlow.html> model that is > now commonly used by many developer teams. In particular, we create feature > branches that use the prefix feature/, and we have a Jenkins job configured > to build any push to any branch matching the pattern 'origin/feature/**'. > Developers work on these branches in parallel, so the order they are > committed is not in any logical sequence. That is, it doesn't make sense > for the jenkins job to consider the change set for the job to be the > difference between the commit being built, and the commit built in the last > successful run of the job. Rather, we'd like the set of changes to simply > be the changes contained in the push. Is there any way to support this > model? > > A different but related concern is what the job for building feature > branches should do when it cannot keep up with multiple independent pushes > of feature branches happening in quick succession. We currently have to > throttle these jobs to run just one job at a time, and the jobs take > approximately an hour. I think we'd like to ensure that every one of these > pushes is eventually built, even if it results in a backlog that is only > eventually cleared in the middle of the night. We are working on ways to > allow jobs to run in parallel, but may have to live with the current setup > for a month or two. In the meantime, is there a way to add jobs to the > queue immediately, with the exact commit to build specified in the 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. > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- 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. For more options, visit https://groups.google.com/d/optout.
