[Buildbot-devel] Access the source stamp from a shell command
warner-buildbot at lothar.com
Tue Sep 27 22:55:48 UTC 2005
> > 2a: .changes is empty, .revision is None, which means "build HEAD"
> This is the case I am seeing - I believe they are both None. I *do*
> want to "build HEAD" I suppose, but I want to know what HEAD means to
> this particular build.
Well, to be honest, "build HEAD" doesn't have much meaning beyond the current
moment. This case is only meant to be used by things like the "Force Build"
button, where you don't much care what exactly is getting built. In somewhat
more technical terms, "build HEAD" is not invariant across time, and the
results of the build will depend upon when exactly the build gets performed.
In contrast, when there are Changes driving the process, the SourceStamp will
(somehow) specify a specific revision of the tree, so that it doesn't matter
when the build gets performed. This also means such builds are repeatable,
whereas pure "build HEAD" builds are not.
Each VC system is supposed to look at the SourceStamp object and figure out
how to check out the right version of the code. When there are Changes
involved, the goal is to take the highest revision number (for VC systems
that use serialized revisions, like pretty much everything except CVS) and do
a checkout at that rev. This is the responsibility of methods like
SVN.computeSourceRevision, rather than something in the SourceStamp class
itself, because it is VC-specific, and I didn't want to have a dozen
different VC-specific subclasses of both buildbot.process.step.Source *and*
SourceStamp. The downside of this choice is that it is harder for your
BuildStep to figure out the right revision number, since it has access to the
SourceStamp (at self.build.source) but not generally to a Source-subclass
Step (where a suitable computeSourceRevision method lives).
> P4Poller does seem to be returning Change objects with the revision
> set; however, it is creating SourceStamp objects anywhere, just Change
> objects. I thought/hoped these would be put into the SourceStamp's
> change list, but they are not there. The changes *do* show up in the
> web view and everything, just not in that particular object.
Like all ChangeSources, P4Poller's responsibility ends with submitting a
Change object via self.parent.addChange(c) . It is the Scheduler's job to
collect those Changes into a SourceStamp, so take a look at the Scheduler
that you're using and double-check that the SourceStamp constructor call
(usually in the timer-expired method) is getting the right list of Changes.
There might be a bug in the Scheduler class that's causing the wrong list
(perhaps an empty one) to be handed to the SourceStamp(changes) call.
hope that helps,
More information about the devel