continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marica Tan <>
Subject Re: In distributed build, how does Continuum decide whether there have been scm changes?
Date Mon, 26 Jan 2009 12:43:58 GMT
On Mon, Jan 26, 2009 at 12:31 PM, Wendy Smoak <> wrote:

> On Thu, Jan 22, 2009 at 7:07 PM, Marica Tan <> wrote:
> > IMO the master needs to keep track of the revisions so
> > that when agent 1 tries to build project @ 4:00pm it will only update the
> > working copy but it won't build the project.
> I'd like to avoid having the master check out the source code.  That
> would require the master to have enough disk space for *all* the
> projects, when all the master really needs to do is serve the webapp
> and fire off build on schedules.
> > Our initial plan is to have a dumb build agent so all it knows is how to
> > build. When it's a scheduled build, it will always build regardless if
> there
> > is or there isn't any change at all. We can add the check for whether it
> > should build or not in the next pass.
> Are you saying this is how it works in 1.3.1, that a scheduled build
> always builds regardless of whether there are scm changes?

Yes, in a distributed build.

> > It first updates the working copy and then set the project's scm result
> > (with scm changes). Project has a one to one relationship with ScmResult.
> > Everytime you update the working copy, it merges the new scm changes with
> > the old scm changes unless it says build fresh.
> >
> > Currently, no scm changes is returned to the master in a distributed
> build
> > and I'll be working on that next.
> How will this work?  Any given agent isn't guaranteed to even have the
> code checked out.

Add project
1:00 Build on agent 1, checkout r100, scm result has no scm changes -->
should build because it's a first build
1:30 commit changes
2:00 Build on agent 2, checkout r101, scm result has no scm changes -->
should build because there are changes
2:30 commit changes
3:00 Build on agent 2, update r102, scm result will have scm changes from
r101 to r102 --> should build because there are changes
3:30 Build on agent 1, update r102, scm result will have scm changes from
r100 to r102 --> should not build since we already build r102 from agent 2

So here's my problem. As you can see from the scenario above, when it tried
to build from agent 2 at 2:00, it checked out the project at r101 with no
scm changes.
How can it get the changes from r100 to r101? This also happens at 3:00. It
only gets the scm changes from r101 to r102. It can only have the scm
changes from r100 to r102 if it build on agent 1 again just like at 3:30
(merging of scm results will happen).

Do you know how to solve this? Any suggestions?

Here's also a solution on what Wendy wants: (though i'm not that familiar
with version controls, just know how to use one, so I don't know if this
will work)

1.) agent updates checkout
2.) return result with revision number?
3.) master checks if up to date and perform other checks to determine
whether agent should build the project or not. scm result may need an
additional field like "Revision Number"
4.) master then decides whether to let the agent build or not based on #3

Is it possible to get the revision number when we do an update in continuum?


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