Confirmed users
353
edits
EngineeringProductivity/Projects/Treeherder/Meetings/2013-01-23: Difference between revisions
Jump to navigation
Jump to search
EngineeringProductivity/Projects/Treeherder/Meetings/2013-01-23 (view source)
Revision as of 00:32, 30 January 2013
, 30 January 2013→Build Objects
| Line 4: | Line 4: | ||
* Define build base object | * Define build base object | ||
** Not specific to builbot per se but would have everything we need based on what ever kind of build we are working with. However the data we are working with now is really messy and inconsistent. The structure will need to be pretty flexible to accomodate this. | ** Not specific to builbot per se but would have everything we need based on what ever kind of build we are working with. However the data we are working with now is really messy and inconsistent. The structure will need to be pretty flexible to accomodate this. | ||
* One option for flexibility would be to have a object store that accepts more attributes that aren't on all objects (the set of required attributes would be small) -- similar to what we did with datazilla. The index of the attributes could be project specific. | |||
* There will be a core set of attributes that all objects have to have but the specifics will differ among various projects. | |||
* Could put a proxy inside the build network so that the build system would not have to use auth to talk to this tool but things outside the build network would. The proxy could implement OAuth for the build network to simplify things. | |||
== Test Objects == | == Test Objects == | ||
* Test data will be stored in a dedicated objectstore as well and then datazilla/orangefactor/graphserver will query this. This will also break the synchonicity between the downstream systems and the build automation. Putting it in one object store will make it easier to scale and to make it more reliable. | * Test data will be stored in a dedicated objectstore as well and then datazilla/orangefactor/graphserver will query this. This will also break the synchonicity between the downstream systems and the build automation. Putting it in one object store will make it easier to scale and to make it more reliable. | ||