Smoke is basically a database of data on projects, builds, test results, and
performance metrics. There is an API for adding such data (the Smoke Client
API) and web front-end to viewing this data. This document describes the
database schema used to store Smoke data.
There are 7 primary database tables plus one addition attributes table for
each of these, for a total of 14 tables. The primary tables are:
| Table |
Description |
|---|
| project |
Each row defines a project for which there might be build,
test and perf results. |
| machine |
Each row defines a machine on which builds, tests or
performance measurements might have been carried out. |
| build |
Each row represents a build for a project package. |
| testspec |
Each row represents a test specification (or type) for a
project. Any test table entry must refer to a testspec. |
| test |
Each row represents a regression test result on a specific
build. |
| perfspec |
Each row represents a performance metric specification (or
type) for a project. Any perf table entry must refer to a
perfspec. |
| perf |
Each row represents a performance measurement on a specific
build. |
Each of the above tables also has an attributes table to allow the
assignment of arbitrary name/value pairs of data to any entry.
Bolded fields are required.
The project table captures project meta-data and provides a way to group a
collection of regrssion test (testspec table) and performance metric
(perfspec table) specifications relevant to a project.
| Field |
Type |
Description |
|---|
| id |
int |
A unique numeric id assigned by the
backend database. |
| name |
string |
A unique short name for a project. |
| fullname |
string |
A longer, "prettier" name for the
project. This is typically used for
display in UI whereas the name field
is used in URLs in the web front end. |
| description |
string |
|
| Field |
Type |
Description |
|---|
| id |
int |
A unique numeric id assigned by the
backend database. |
| machine_id |
int |
The machine on which this build was
built. |
| project_id |
int |
The project to which this build belongs. |
| package |
string |
The name of the package that was built
(e.g. installer, source, documentation).
This field allows for different packages
for one project. |
| version |
string |
Version of the built package. |
| starttime |
datetime |
Time at which the build was started. |
| is_dev_build |
boolean |
Boolean indicating whether this entry
identifies a development build. See
the getDevBuildId() Client API method. |
| scc_revision |
string |
Source code control system revision to
which this build can be linked (if
possible). |
| build_flags |
string |
Special configuration build flags. |
| environment |
string |
Dump of relevant/special environment
settings. |
| log_file |
string |
In the database the path to a local copy
of any uploaded log file is stored here. |
| result |
boolean |
Indicates if build was successful. |
| checksum |
string |
MD5 digest of the built package, if
available. |
Notes on scc_revision: If this can be specified then it may be possible for
the Web front-end to provide useful direct links from build/test/performance
data to specific change descriptions, e.g. to a specific revision on p4db:
http://caliper.activestate.com/p4db/changeView.cgi?CH=51234
Notes on checksum: using an md5sum of a build's installer is an excellent
way to uniquely identify a built package. Obviously, such a checksum can only
be obtained if there is a successful build. See the getBuildId() Client API
method.
Notes on is_dev_build: Development build entries are treated somewhat
differently. A development build is, in general, not trackable. It changes
with time. None of scc_revision, build_flags, starttime, environment,
checksum are applicable. This concept exists in Smoke to allow the adding
of test data for development builds without the burden of having to add new
build entries for every such test.
Each type of regression test for a project that is added to a Smoke database
must refer to a testspec entry. A test specification belongs to a
specific project and is uniquely defined by its name and project_id
(see the getTestSpecId() Client API method).
| Field |
Type |
Description |
|---|
| id |
int |
A unique numeric id assigned by the
backend database. |
| name |
string |
A short name for this test specification. |
| project_id |
int |
The project to which this test type
belongs. |
| fullname |
string |
A longer, "prettier" name for the
test spec. This is typically used for
display in UI whereas the name field
is used in URLs in the web front end. |
| description |
string |
|
| Field |
Type |
Description |
|---|
| id |
int |
A unique numeric id assigned by the
backend database. |
| testspec_id |
int |
The test specification defining meta-data
about this test result (such as what
project it belongs to). |
| build_id |
int |
Identifies the build that was tested. |
| machine_id |
int |
Identifies the machine on which the test
was run. This may differ from the machine
on which the package was built. |
| starttime |
datetime |
The time at which this test was begun. |
| result |
boolean |
Indicates whether the test was
successful. |
| log_file |
string |
A log of the test run. In the database
the path to a local copy of any uploaded
log file is stored here. |
There is one *_attributes table for each of the primary tables described
above. Each such table has the same basic structure:
| Field |
Type |
Description |
|---|
| <tablename>_id |
int |
Refers to entry in its associated table. |
| name |
string |
Cannot contain a newline or '='
character. |
| value |
string |
Cannot contain a newline character. |
