On Wed, Nov 21, 2012 at 12:50 PM, Nathan Neulinger <nn...@neulinger.org> wrote:
>
> Southern:
>   Project 1, builds, and repositories
>   Periodically sync over builds to California site for product testing
>
> Western:
>   Project 2,3,4,5,6, builds, and repositories
>
> Asia:
>   Currently makes use of build output from projects 3,4,5,6
>
> I'd really like to manage all of the build configurations from one place,
> but I'm not seeing any good way to do that other than stuff like configuring
> it to not archive binaries, but rather do that myself with command/step
> executed at the end of the build or similar. Similarly, being able to define
> the build once centrally, but run it independently at each of three sites so
> a local copy is available at that site, but without constantly sending all
> the resulting build data around. (multiple gigabytes of build output per
> build)
>
> Same sort of concerns as the checkouts from VCS as well - would ideally like
> the checkouts to be maintained at the individual sites so I'm not sending a
> full checkout from the central server.

The bulk of the traffic is going to be between the VCS and the build
slave - plus wherever you collect the build results.   Jenkins
instances aren't particularly hard to manage - and you normally don't
even need to interact with them that much once the job is created in
the first place.  I'm not sure I see what problem you want solve by
combining sites that don't have much in common.  If your connectivity
isn't good, why bother?   I'd just push anything you need across sites
into something like a subversion repository that everything can access
so you only have to move the pieces actually being used.

-- 
   Les Mikesell
      lesmikes...@gmail.com

Reply via email to