Bitten Data Storage

The data generated by automated builds can almost always be mapped to the physical and/or the logical view of the code base, where the physical view corresponds to files and line numbers, while the logical view is composed of units such as packages, classes and functions. Specific metrics basically annotate either view with the extracted information. The structure of the annotation, however, depends entirely on the type of metric.

For example, test results might have the following attributes:

• Name of the test
• Result: success, failure or error
• Error message and stack trace (in case of an error or failure)
• Output of the test (standard error and output streams)
• Time it took to execute the test

Code coverage, on the other hand, might look like this:

• Name of the unit (module, class, etc)
• Total lines of code in the unit
• Percentage of lines executed
• Number of times every lin was executed

Other data such as compilation errors/warnings or style checks would consist of the message of the error or warning.

Database Layout

As Bitten should support the storage of arbritray metrics, the tables for storing this data need to be fairly generic. Versions of Bitten prior to 0.5 used a Berkeley DB XML backend to store reports, but for various reasons the report data is now mapped to tables in the relational database already provided by the Trac environment.

A report is received in XML format from the build slave, for example:

<report type="unittest">
  <test duration="0.073" status="success" fixture="bitten.tests.model.BuildConfigTestCase" name="test_config_update_name" file="bitten/tests/model.py"/>
  ...
</report>

Querying the Report Store

TBW