[Buildbot-devel] Welcome to the "Buildbot-devel" mailing list

[Dustin J. Mitchell]

On Wed, Jul 1, 2009 at 12:47 PM, Zellyn Hunter<zellyn+buildbot at gmail.com> wrote:
> I'd like to propose setting revision to None before calling startVC if
> alwaysUseLatest is set. But, I don't want to break anything else.

The patch is here, btw:
  http://github.com/zellyn/buildbot/commit/97aa04aa47a4ae3074446d22b377ef9a4f8ebbf2

> Comments? Suggestions? Am I understanding correctly?

For background for everyone else:

ChangeSources produce Change objects, each of which has a revision.
Schedulers then consume these Change objects and queue BuildSets which
lead to BuildRequests which lead to Builds.  The schedulers are also
responsible for creating a SourceStamp for each new BuildSet.

A SourceStamp is not as literal as its name might suggest -- it can
specify nothing (meaning "the latest on the default branch"), or just
a branch ("latest on this branch") or a revision ("this revision on
the default branch"), etc.

So, for example, the Nightly scheduler produces "latest"-style
SourceStamps, since it doesn't consume changes and thus doesn't know
what revision it should build.  Forced builds produce various
SourceStamps, but usually have a fixed revision.  The regular
Scheduler scheduler, however, builds a SourceStamp from the Changes
that have accumulated in the treeStableTimer's duration.  The
SourceStamp constructor takes its revision from the latest of these
Changes.  The result is, of course, a SourceStamp with a fixed
revision (not "latest").

In the current implementation, when a Source step gets a SourceStamp
without a Change object, it builds a revision from the set of changes
in the SourceStamp:
  revision = s.revision
  if not revision and not self.alwaysUseLatest:
    revision = self.computeSourceRevision(s.changes)

But if s.changes is set, then the SourceStamp constructor itself would
have set s.revision, so this code would never be triggered.

The upshot is that, as far as I can see, computeSourceRevision is
never used (which is unfortunate, since it applies the checkoutDelay
for CVS), and thus alwaysUseLatest is a no-op.

So, on reflection, I'm in support of merging this change to make
alwaysUseLatest *always* use the latest revision, even if there's an
explicit revision given in the SourceStamp.  The upshot is that
specifying a revision in the force-build form won't work, if
alwaysUseLatest is in use.

Opinions?  Zellyn, if you don't hear anything in a short while, ping
me and I'll merge the change.

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com