Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <33D5314A-C6FA-446F-81DF-339D66A2BB29@israfil.net>
From: Christian Edward Gruber <cgruber@israfil.net>
To: dev@continuum.apache.org
In-Reply-To: <adba96190901170928i5aa2de3ewa8feedfe6d0d14ee@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Subject: Re: Associating projects with distributed build agents
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Sat, 17 Jan 2009 12:47:02 -0500
References: <adba96190901170928i5aa2de3ewa8feedfe6d0d14ee@mail.gmail.com>

Rather than agent groups, could we go with a criteria approach?  That =20=

is to say, you can describe and agent's capabilities, then associate =20
criteria for a project group or project, and then let the system sort =20=

out which agents can fulfill which criteria?

Christian.

On 17-Jan-09, at 12:28 , Wendy Smoak wrote:

> One of the goals at the top of the Distributed Builds wiki page is the
> ability to build on multiple platforms.
>
> As we've discussed in some other threads and on irc, we need some way
> of telling Continuum which agent(s) to execute builds on.
>
> To me, it seems like this belongs as a field on the build environment,
> which is then selected on the build definition.
>
> That would be a good next step IMO -- to pin a particular build def to
> a particular agent through the environment.
>
> However, I don't want to lose the effect of distributed builds in
> parallel that we're getting from the current 'next available'
> selection.
>
> So, how does having groups of agents sound?  Then you could associate
> a build environment with a pool of agents, and the next available one
> of those would be chosen.
>
> You might have a large group of identically configured Linux boxes
> that most of your builds can be distributed to.  However, maybe there
> is one special project group that needs their own private pool to work
> on a top secret project.  Another team might be targeting Solaris and
> want to do their builds on a pool of three Solaris boxes.  And of
> course the project that only builds on Windows needs to always build
> on the one Windows agent you have reluctantly configured for them. ;)
>
> There's an additional requirement that the system admin must be able
> to limit which environments a project team is allowed to choose.
> While a project developer can modify build definitions and add new
> ones, he should not have free choice of *all* the available
> environments.  This probably means adding an "Allowed Build
> Environments" field to the project group.
>
> How does that sound?  Does anyone have a different idea of how this =20=

> should work?
>
> --=20
> Wendy
>

Christian E. Gruber - President / Senior Consultant               =20
email:  cgruber@israfil.net
Isr=E1f=EDl Consulting Services Corporation                           =20=

mobile: +1 (289) 221-9839
"Keenness of understanding is due to keenness of vision..."       =20
phone:  +1 (905) 640-1119