Design Notes

Build Objects

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.
One option for flexibility would be to have an 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 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.
Generation of Test Objects, in many cases, is done through log parsing. This part of the project has hard dependencies on other log parsing clean up projects.
Test objects should not be limited to data from logs. If you could have raw log, parsed log, and references to binary locations, screen shots, recordings during tests, etc all could be keys inside results dictionary.
Parsed logs would be all the data from the log - python lib that the slaves could use to parse the log before upload but the raw log would also be uploaded as well.
- Note: Not sure we need to store the raw log separately, could just store a pointer to it. How does the storage of raw logs currently work? How long do we keep them for?
Some of the test automation frameworks generate their own summaries and buildbot generates its own summaries on top of that, this should be cleaned up as part of this effort or alongside it.
- This should be done in mozharness not in buildbot
The build object can have any number of test objects associated with it.
There are logs outside the tests - the buildbot master log etc.

How do we maintain the ordered pushlog?
The current way to do that is to review the pushes from hg and then combine that with data from the build system and generate the pushlog
would be great to have a webservice that gives you a unified view of the pushlog so that all downstream apps can use it
we need this for git not just hg

There needs to be some way to see and understand what the status is of these auxiliary build/test jobs that run more periodically - valgrind, QA update tests etc.