continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marica Tan" <c...@exist.com>
Subject Re: First Part of Distributed Builds
Date Mon, 12 Jan 2009 14:38:01 GMT
On Sat, Jan 10, 2009 at 12:52 AM, Wendy Smoak <wsmoak@gmail.com> wrote:

> On Thu, Jan 8, 2009 at 11:32 PM, Marica Tan <ctan@exist.com> wrote:
>
> > Thanks wendy for trying it out. I'm thinking of merging this to trunk
> this
> > weekend so please do comment on it if you have any objection.
>
> I think it needs to be documented first.  Right now I can't be sure
> it's doing what it's supposed to, only that it seems to be doing
> something reasonable. :) Is the wiki [1] up to date?


Nap is already working on the documentation. Wiki[1] needs to be updated.

>
> I had a few questions as I went through it:
>
> Is a slave the same thing as a build agent?  The naming is inconsistent.
>
> SLAVE_HOME should probably be CONTINUUM_SLAVE_HOME (or _AGENT_) for
> clarity and to avoid conflicts with other software.
>

Slave is the same as a build agent. Change it to CONTINUUM_BUILD_AGENT?

>
> When I add a project to the master, it still checks out the source
> code on the master even though the distributed builds option is
> enabled.  Should it?  (Is it so that it can decide whether there have
> been any changes?)


Hmm... no it shouldn't. Will fix this.

>
>
> What about security?  I didn't set up any users on the slave, can
> anyone who knows the url add projects and execute builds?


We don't use database in the slave so no redback. Will include documentation
on how to secure communication through SSL, though not sure if it's enough
for security.

>
> What are the installations in the config file used for?  I noticed
> that if I added an installation/buildenv to the master and executed a
> build using it, the slave used it (the correct version of Maven) even
> though it was not listed as an installation in the slave's config.
>

Supposed to be, when you attach a slave to the build environment, all
installations in the slave will be copied to the master and you can only add
installations to the build environment from those installations.

Let's say MASTER has INSTALLATIONS_1, and INSTALLATIONS_2. SLAVE_A has
INSTALLATIONS_3, and INSTALLATIONS_4.

When user attached SLAVE_A to BUILD_ENVIRONMENT_A:
1. Remove all previous installations of BUILD_ENVIRONMENT_A
2. Copy INSTALLATIONS_3 and INSTALLATIONS_4 to MASTER
3. BUILD_ENVIRONMENT_A can add installations from those of SLAVE_A's only (
INSTALLATIONS_3 or INSTALLATIONS_4 )

So if a build definition has a build environment attached to it, the slave
will use the installations of that build environment.


>
> We need to consider possible interactions with existing features.  I'm
> not saying we need to deal with them all before merging this, but we
> should be aware of it and document what happens.  For example... How
> do you purge local repositories on slaves?  How does releasing work?
>

Will document this.

>
> As previously mentioned, the current implementation only works if all
> your slaves are identical.  The ability to choose which slave(s) a
> project is allowed to build on needs to be added at some point.
>
> Also, we're already blocked from releasing trunk because we have no
> database migration capability.  Given that the target market for
> distributed builds is Continuum users who have _multiple_ instances,
> how are they going to migrate and combine multiple sets of
> configuration into one master server?
>
> Great job on all this!  All in all, +1 to merging it with
> documentation, after Emmanuel's concerns are addressed.
>
> [1]
> http://cwiki.apache.org/confluence/display/CONTINUUM/Distributed+Builds
>
> --
> Wendy
>



-- 
Maria Catherine Tan
Software Engineer | Exist Global | +632 687 4091 loc 301 | skype: marica_tan
| www.exist.com | Innovation Delivered

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