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.

Reply via email to