[Buildbot-devel] Accessing other Build's properties from a BuildStep

[Brian Lalor]

On May 28, 2013, at 3:56 AM, Daniel Rus Morales <danirus at eml.cc> wrote:

> I don't quite get the scenario. Could you elaborate more? 
> What's your starting point and what's the flow you have in mind?
> 
> With properties you can go quite far
> (http://docs.buildbot.net/current/manual/cfg-buildsteps.html#setproperty).
> You could use a function to look into the property and associate the
> function with the argument doStepIf of your BuildStep.

Here's a quick and dirty diagram of two states: all projects in development mode, and projects A, B and E have been released.  The arrows indicate a dependency: E depends on B, and B depends on A.  When A completes successfully B should be built immediately afterwards; when B completes, C and E should build.  And so on.  On the right side of the diagram, several projects (A, B, E) have had releases and are now producing a new version of an artifact; the dependency relationship between some of the projects has been broken because the downstream projects are no longer depending upon the version of the artifacts being created by A, B and E.



For each of these projects, you can assume that they produce one or more artifacts (WARs, JARs, tarballs, what have you), and that they depend on zero or more artifacts produced by other projects in this BuildBot instance.  The relationships are not known when master.cfg is parsed (ie when the master is started).  The only thing that's known when the master is started is that each of these projects (A .. F) exist, and how they are built.  After each build, I am setting properties that indicate what the project provides (outputs) and what it requires (its build or runtime dependencies).  The actual artifacts are stored in an external artifact repository (Nexus, in my case); each project pulls its requirements from Nexus at build time.  Since the dependencies are stored in Nexus, each project can be built on its own, but the intent here is to trigger downstream builds as soon as possible to when a depended-upon project changes.

The provides and requires properties are set on each Build (as they could change from build to build as dependencies change).  My intent is to have a Triggerable scheduler attached to each builder, and then a build step that will kick the Triggerable for each downstream project (one whose requires list contains an item in the current build's list of provides).  The DownstreamTrigger will examine the provides of the current build and match them up with requires of other builds in the master.

Now that I've figured out how to query the properties of the last build implementing the DownstreamTrigger build step is largely academic.  I'm finding it much more difficult to implement build steps than I would have expected, however. :-(


--
Brian Lalor
blalor at bravo5.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20130528/4acf6181/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled 2.jpeg
Type: image/jpg
Size: 15483 bytes
Desc: not available
URL: <http://buildbot.net/pipermail/devel/attachments/20130528/4acf6181/attachment.jpg>