This is how I manage building a pile of different client variations for iOS and Android. (They each have their own matrix job set.)
Ben On Thu, Aug 30, 2012 at 9:31 AM, bearrito <j.barrett.straus...@gmail.com> 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. > > -b > > On Wednesday, August 29, 2012 1:44:34 PM UTC-4, LesMikesell wrote: >> >> On Wed, Aug 29, 2012 at 11:38 AM, bearrito >> <j.barrett...@gmail.com> 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 >> lesmi...@gmail.com
