[Buildbot-devel] Welcome to the "Buildbot-devel" mailing list
Dustin J. Mitchell
dustin at zmanda.com
Thu Jul 2 15:14:50 UTC 2009
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:
> 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.
Open Source Storage Engineer
More information about the devel