On Mon, Jun 4, 2012 at 6:23 AM, Bram de Jong <bram.dej...@samplesumo.com> wrote:
>>
> My initial guess on how to solve this:
> * put each of the repo's in a job that *only fetches* the repo into a
> shared directory and doesn't do anything else.
I'd think in terms of jobs that build components and applications, not
so much in relationships to repositories.
> * use the join plugin to create different pipelines (apps in A only
> need A, apps in B need A+B, apps in C need A+B+D+C)
Where the code is in subversion, you might use svn externals to pull
the components in instead of anything special in jenkins.
> * use a mac with windows and linux VM, set up windows and linux as slaves
The VM's act the same as real machines, so you can use whatever is
convenient with sufficient performance. It is a good idea to give the
slaves labels that reflect the build capabilities and restrict the
jobs to labels rather than specific nodes so it is easy to expand the
pool for more capacity.
> Some questions:
> * I would love some feedback on this whole configuration and my plan of attack
I'd start with jobs that approximate whatever you are doing manually.
Aside from having fewer surprises, you want developers to be able to
do their own test builds before committing and have the same thing
happen in the integration run.
> * Does it make sense to try to use of the parameter-ised builds for
> building the apps on various compiler/platforms? I'm worrying that
> each of the jobs that do this will need something special/unique for
> each platform.
That's easy enough to change if you see you need it (you notice you
are creating many copies of a job for a single project with small
differences). You may be more interested in the matrix build
capability if you build the same thing on several platforms, and for
that you need to execute the same command on each so you may need the
Xshell or groovy plugins to handle the variations.
> * Would it be best to put the master on osx/windows/linux? With the VM
> system I propose it doesn't really matter who the master is..
I'd run it on linux since it is probably the best-tested platform.
> * Do you have any hints of things I should read?
It's not that complicated, at least to get started.
> * All of the apps share/assume the same file structure. Will this get
> me into as much trouble as I think it will - jenkins being built
> around the idea of each app having a separate workspace?
Yes, with the possible exception of svn externals, you'll need to
arrange for each job to archive its build results and for anything
else that needs them to copy them wherever they need to be. It is
probably possible to make jenkins leave the file structure alone and
do builds that just happen to work because needed components are
already there, but it seems like a really bad idea and doesn't mesh
well with distributed build farms.
--
Les Mikesell
lesmikes...@gmail.com
