continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marica Tan <marica....@gmail.com>
Subject Re: Proposal for CONTINUUM-2476
Date Tue, 06 Apr 2010 00:39:50 GMT
On Mon, Apr 5, 2010 at 10:01 AM, Deng Ching <oching@apache.org> wrote:

> On Mon, Apr 5, 2010 at 7:57 AM, Marica Tan <marica.tan@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message