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. -b On Wednesday, August 29, 2012 1:44:34 PM UTC-4, LesMikesell wrote: > > On Wed, Aug 29, 2012 at 11:38 AM, bearrito > <[email protected] <javascript:>> wrote: > > Why the insistence on single job? > > > > Jobs are cheap in Jenkins and it doesn't make sense to couple building > > binaries that don't have anything to do with one another except the > source. > > > > I would have a job per binary. I would run them all in parallel using > either > > the Join Trigger Plugin or the BuildFlow Plugin. > > A matrix build should work too, if you can come up with a wrapper > script that you can run with the xhell or groovy plugins so you can > execute the same command on all platforms to do the build. But I'm > not sure there is that much advantage over separate jobs polling for > scm changes. > > -- > Les Mikesell > [email protected] <javascript:> >
