I was just thinking of the case where the executor on one of the slaves is busy so isn't immediately able to begin working between on a commit. You could potentially have a race condition in terms of commits. You can of course get around that by blocking on upstream builds.
On Thursday, August 30, 2012 1:19:56 PM UTC-4, LesMikesell wrote: > > On Thu, Aug 30, 2012 at 11:31 AM, bearrito > <j.barrett...@gmail.com <javascript:>> wrote: > > I don't think you even need separate polling per job. > > > > 1. Have single root job that is hooked to SCM > > 2. Pull updates from SCM > > 3. Push new source code to job workspaces. > > 4. Jobs can independently compile src. > > 5. Run job specific tasks such as : Jobs can run tests on their specific > > mobile emulators. > > > > > > Everything from step 3 onward can be done in parallel. > > You can do that, but it only seems worth the effort if you care about > saving network traffic between jenkins and the SCM. In our case they > are in the same lab on a fast network so a few extra checkouts or > updates aren't a problem. If the commits are frequent, though, you > might want something to tie the versions of the builds together so > subsequent testing etc. would all match. > > -- > Les Mikesell > lesmi...@gmail.com <javascript:> >
