[Buildbot-devel] Build Properties through the DB / data API

Benoît Allard benoit.allard at greenbone.net
Mon Nov 17 18:09:50 UTC 2014

Hi there,

I wish to get the build properties available to the new shiny web 

As I understood, to get this working, we need to make them available to 
the data API (the only interface to the web interface), and this data 
API needs to retrieve it from the DB.

I started creating a new table 'build_properties', with a buildid, a 
name and a value, nothing fancy, just the necessary to get it working. I 
inspired myself from buildset_properties and change_properties, both 
also do it that way. Then I thought, I *just* needed to wire my table to 
the data API, and all calls from buildbot setting / retrieving the 
properties would automatically be backed-up in the DB, hence available 
to the web interface ... Turned out to be quite a naive idea ...

Back in eight's time, build properties used to be the properties that 
are related to a specific build. I.e. all values accessible through a 
`WithProperties` call. They include change properties, buildset 
properties, as well as a dozen of other source for properties. For 
instance, the build itself sets some, and some steps also do. Some come 
from the config, other from the schedulers, even the builders can set 
some. All properties regardless from origin were gathered in the build 
object, saved as pickle on disk, and the content of that pickle was 
displayed in the web interface. Back in the time, everything seemed easy 

Now I'm quite confused.

What are, according to our master branch 'build properties' ?

They obviously don't include change properties, or buildset properties 
(as, those already have their own DB table), but, are global config 
properties also build properties ? and the slave properties do they also 
belong to the build properties family ? The one that interest me the 
most, the one I set when analysing my logs, the step properties, are 
they also build properties ? Or are they respectively 'global 
properties', 'slave properties', and 'step properties' ?

That could be a way to go, create a new dozen of tables: 
'global_properties', 'slave_properties', 'step_properties', ... But is 
it worth it ? Aren't they all 'properties' after all ? Who will care of 
gathering them all ? and linking the right setProperty call with the 
right table ? Remember, at the end, I still want to see that complete 
list on my web page !

Here I am, lost in a sea of properties. I hope someone can shed some 
light !


More information about the devel mailing list