The following information needs to be in each build data (I assume each build attempt can send out multiple build data, and there is "runtime" attribute to group those data into batches).
0. timeStamp (not very meaningful, general sdt requirement) 1. buildResult (success or failure) 2. failureType (none/unittest/checkstyle/...) 3. failureMessage (...) 4. runtime (to associate build data into batches) 5. startTimeMillis (build start time) 6. endTimeMillis (build end time) 7. project (current debating, should we use build.xml file name?) 8. configuration (Hackystat-UH/ALL/JPL) 9. startType (CC-auto/CC-manual/Workstation-manual) 10. checkstyleRunned (true/false) 11. compilationRunned (true/false) 12. unittestRunned (true/false) 13. failureModuleName (hackyKernel/hackyStdExt/...)
Philip wants: 14. buildTarget (junitAll/compileAll/quickStart/...) (I think it's feasible, the last target invoked should be the one needed)
Current question: Should we use fully qualified name of build.xml instead of projectId? This does not solve every problem, but is better than hard-coding approach.
Mike and Aaron: If there is any additional information you guys need, can you email me today?
Philip: As far as build analysis is concerned, 1-13 is mandatory, but you might have more general/broader perspective. Can you let me know what should really go into required fields?
Thanks.
Cedric
Should we change the "ProjectID" field in the Build SDT to a "BuildFile" field, and use the workspace associated with that fully qualified file name to determine the Project?
Does anyone see any problems with that change?
Cheers, Philip
