Database

The Release Manager databases no longer use the mysql server setup on glastDB.slac.stanford.edu. The tables are now stored on mysql-node03. Read only access to the databases are provided via the same glastreader account as on glastDB. Write access is restricted to machines located at SLAC.

Layout

The Release Manager tables are now significantly different from the original tables used with CMT. Most of these changes are to improve on the previous design but there are also changes due to SCons. The database name is rd_releasemgr. All tables are InnoDB engines and fields that have the same name are tied to each other via foreign keys.

General Tables

There are four tables that provide general information about which OSes, Packages, and the types of build variations the Release Manager keeps track.
These four tables look as follows:

The os table lists all the Operating Systems that the Release Manager will compile on. (Ex. redhat4-i686-32bit)

+--------+---------------------+------+-----+---------+----------------+
| Field  | Type                | Null | Key | Default | Extra          |
+--------+---------------------+------+-----+---------+----------------+
| osId   | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| osName | varchar(255)        | NO   | UNI | NULL    |                |
+--------+---------------------+------+-----+---------+----------------+

The package table lists all the top level packages the Release Manager will keep track of. (Ex. ScienceTools, GlastRelease)

+-------------+---------------------+------+-----+---------+----------------+
| Field       | Type                | Null | Key | Default | Extra          |
+-------------+---------------------+------+-----+---------+----------------+
| packageId   | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| packageName | varchar(255)        | NO   | UNI | NULL    |                |
+-------------+---------------------+------+-----+---------+----------------+

The variant table lists all the variations of a build the Release Manager will perform. (Ex. Debug, Optimized)

+-------------+---------------------+------+-----+---------+----------------+
| Field       | Type                | Null | Key | Default | Extra          |
+-------------+---------------------+------+-----+---------+----------------+
| variantId   | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| variantName | varchar(255)        | NO   | UNI | NULL    |                |
+-------------+---------------------+------+-----+---------+----------------+

The versionType table will list all the version types the Release Manager will keep track of. (Ex. Releases, HEAD, LATEST).

+-----------------+---------------------+------+-----+---------+----------------+
| Field           | Type                | Null | Key | Default | Extra          |
+-----------------+---------------------+------+-----+---------+----------------+
| versionTypeId   | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| versionTypeName | varchar(255)        | NO   | UNI | NULL    |                |
+-----------------+---------------------+------+-----+---------+----------------+

Settings table

The settings table provides settings for the various combinations of the above four tables. If a setting applies to all types of one of the particular tables above, it's ID is specified as NULL. For example if a setting applies to all OSes, then the osID field is specified as NULL.

+---------------+---------------------+------+-----+---------+-------+
| Field         | Type                | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+-------+
| packageId     | bigint(20) unsigned | YES  | MUL | NULL    |       |
| osId          | bigint(20) unsigned | YES  | MUL | NULL    |       |
| variantId     | bigint(20) unsigned | YES  | MUL | NULL    |       |
| versionTypeId | bigint(20) unsigned | YES  | MUL | NULL    |       |
| name          | varchar(255)        | NO   |     | NULL    |       |
| value         | varchar(255)        | NO   |     | NULL    |       |
+---------------+---------------------+------+-----+---------+-------+

Platform independent information

Some information the Release Manager keeps track of is independent of the various variations that are available. For example the version of a build is the same no matter if it's a debug build or if it's a build for windows or linux. This information is kept in separate table to prevent duplication of information.

The buildPackage table currently contains the version number assigned to a build and a field that specifies if a tag for this version currently exists in CVS.

+----------------+---------------------+------+-----+---------+----------------+
| Field          | Type                | Null | Key | Default | Extra          |
+----------------+---------------------+------+-----+---------+----------------+
| buildPackageId | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| packageId      | bigint(20) unsigned | NO   | MUL | NULL    |                |
| versionTypeId  | bigint(20) unsigned | NO   | MUL | NULL    |                |
| version        | varchar(255)        | NO   |     | NULL    |                |
| cvsTagged      | enum('yes','no')    | NO   |     | yes     |                |
+----------------+---------------------+------+-----+---------+----------------+

Platform dependent information

Most of the information the Release Manager keeps track of is dependent on the variations that are provided by the first four tables described in this document. The most basic of this information is provided in the build table.

The startTime field describe when a build was started while the stopTime field is for when the build has been completed. The checkoutStartTime and checkoutStopTime fields specify when the checkout procedure was performed and completed. The checkoutReturnCode field contains the return code that was returned by the checkout application. The compileStartTime, compileStopTime, compileReturnCode, testStartTime, testStopTime fields contain similar information for the compile and test steps during a build. There is no testReturnCode field because that information is provided per sub package in a different table.

The buildLocation field specifies where this build was performed and is currently stored. The sconsLocation field contains the path to the SCons executable that was used for the build. Finally, the externalsLocation field contains the location of the external libraries that were used for the compile.

+--------------------+---------------------+------+-----+---------+----------------+
| Field              | Type                | Null | Key | Default | Extra          |
+--------------------+---------------------+------+-----+---------+----------------+
| buildId            | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| buildPackageId     | bigint(20) unsigned | NO   | MUL | NULL    |                |
| osId               | bigint(20) unsigned | NO   | MUL | NULL    |                |
| variantId          | bigint(20) unsigned | NO   | MUL | NULL    |                |
| workflowId         | bigint(20) unsigned | YES  |     | NULL    |                |
| startTime          | datetime            | YES  |     | NULL    |                |
| stopTime           | datetime            | YES  |     | NULL    |                |
| checkoutStartTime  | datetime            | YES  |     | NULL    |                |
| checkoutStopTime   | datetime            | YES  |     | NULL    |                |
| checkoutReturnCode | int(11)             | YES  |     | NULL    |                |
| compileStartTime   | datetime            | YES  |     | NULL    |                |
| compileStopTime    | datetime            | YES  |     | NULL    |                |
| compileReturnCode  | int(11)             | YES  |     | NULL    |                |
| testStartTime      | datetime            | YES  |     | NULL    |                |
| testStopTime       | datetime            | YES  |     | NULL    |                |
| buildLocation      | varchar(255)        | YES  |     | NULL    |                |
| sconsLocation      | varchar(255)        | YES  |     | NULL    |                |
| externalsLocation  | varchar(255)        | YES  |     | NULL    |                |
+--------------------+---------------------+------+-----+---------+----------------+

The outputMessage table contains the output from the checkout and compile steps of a build described in the build table above. The type field describes what type of output is stored. This can currently be checkout or compile. The message filed contains the actual output.

+---------+-----------------------------------+------+-----+---------+-------+
| Field   | Type                              | Null | Key | Default | Extra |
+---------+-----------------------------------+------+-----+---------+-------+
| buildId | bigint(20) unsigned               | NO   | PRI | NULL    |       |
| type    | enum('checkout','compile')        | NO   | PRI | NULL    |       |
| message | longtext                          | YES  |     | NULL    |       |
+---------+-----------------------------------+------+-----+---------+-------+

The subPackage table contains information for the sub packages of a build described in the build table. The subPackageName field contains the name of a sub package. The version field contains the version of the subPackage. The compileStatus field specifices if a package compiled successfully or had failures. The testStatus field specifies if the test application for a particular sub package was successful or not. Finally, the testOutput field contains the output from the test application.

The subPackageCompileFailures table contains the individual compile failures for various sub packages. If the compileStatus field in the subPackage table specifices a failure, then this table contains at least one entry showing compile information failures.

The subPackageName field is the same as the subPackageName specified in the subPackage table. The compileBegin and compileEnd fields contain the byte offset from the compile output in the outputMessage table that references where the build failure occured.

+----------------+---------------------+------+-----+---------+-------+
| Field          | Type                | Null | Key | Default | Extra |
+----------------+---------------------+------+-----+---------+-------+
| buildId        | bigint(20) unsigned | NO   | MUL | NULL    |       |
| subPackageName | varchar(255)        | NO   |     | NULL    |       |
| compileBegin   | bigint(20) unsigned | YES  |     | NULL    |       |
| compileEnd     | bigint(20) unsigned | YES  |     | NULL    |       |
+----------------+---------------------+------+-----+---------+-------+

The extLib table contains information about the external libraries used for this build. The name field specifies the name of the external library, the version field specifies the version of the external library. Finally, the libPath field specifies the location of the libraries used for this build.

+---------+---------------------+------+-----+---------+-------+
| Field   | Type                | Null | Key | Default | Extra |
+---------+---------------------+------+-----+---------+-------+
| buildId | bigint(20) unsigned | NO   | PRI | NULL    |       |
| name    | varchar(255)        | NO   | PRI | NULL    |       |
| version | varchar(255)        | NO   |     | NULL    |       |
| libPath | varchar(255)        | NO   |     | NULL    |       |
+---------+---------------------+------+-----+---------+-------+
  • No labels