On Mon, Apr 5, 2010 at 10:01 AM, Deng Ching <[email protected]> wrote:
> On Mon, Apr 5, 2010 at 7:57 AM, Marica Tan <[email protected]> wrote: > > > In distributed builds, here's how a build agent get selected: > > > > [1] Get the build agent where the project in the project group is > currently > > building > > > > [2] If [1] returns null, check if there's a build agent group attached to > > the build definition. If none, proceed to [3], otherwise, get the least > > busy > > build agent attached to the build agent group. > > > > [3] Get the least busy build agent > > > > > > > > A limitation in distributed builds: all projects in a project group will > > build on the same build agent because we assumed that they are > > inter-dependent. > > > > What happened with CONTINUUM-2476 was that when the NIGHTLY_BUILD got > > triggered to run by 11pm, the WINDOWS_BUILD was still running. > > > > So when distributed builds go to the process of selecting a build agent, > > [1] > > returns the WINDOWS build agent, thus building it in WINDOWS instead of > in > > the LINUX_BUILD. > > > > > > > > What I propose is to add checks like those in non-distributed build > > > > - check if the project is in any prepare build queue > > - check if the project is in any build queue > > - check if the project is currently preparing build > > - check if the project is currently building > > > > > This would mean that it would not be possible to build a project > simultaneously in two build agents, right? > Can't it be done that if a project's build is triggered it would still build > it using the build environment attached to the schedule given that it's not > the same build environment that is being used by that same project already > building or in the build queue? > > Yes it could. I'm thinking of checking the project together with the build definition just like with parallel builds. So if it's using a different build definition then it should be allowed. Also interchange [1] and [2]. Thanks, -- Marica > Thanks, > Deng >
