>> 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.
The problem is that this would mean 100 different jobs that all do the same thing (i.e. update 5 repositories - one of which is SUPER slow). Each job will have need approx 10GB of HD space to just have the repositories. I.e. the overhead of having each of the 5 repos reproduced for each of the 100+ jobs would be immense. > Where the code is in subversion, you might use svn externals to pull > the components in instead of anything special in jenkins. But the code is spread in Git and Subversion, not just Subversion. It's a bit of a mixture. Also, there is no way I can reorganize things: reorganizing the structure would mean fixing the build scripts/projects for at leadst 100 applications on 5 different platforms (if you count various version of visual studio as platforms)! > 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. Duly noted! > 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. What I described in my email is exactly what we do: 1. make a super folder 2. check out the 5 repos in there 3. all the apps in those 5 repos now build We don't create a new super folder for each application. >> * 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. Duly noted! >> * 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. Hmm, so this is *definitely* going to get me into trouble... - bram
