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 23:12, 29 January 2013
, 29 January 2013→Test Objects
| Line 9: | Line 9: | ||
== 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. | ||
* 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? | |||
== Pushlog Objects == | == Pushlog Objects == | ||