There are a bunch of different IDs used in the various database tables to identify builds and link the data together. And their naming isn't always consistent. What could be called one thing in one database is used with a different name in others. This page attempts to identify the key IDs and their usage in linking the data together across the rd_releasemgr, rd_workflow, and rd_lsf databases use by the SCons RM system.
A Note on Formatting
Within this page and many of the linked pages the following convention is used to denote the names of database, table, and column names:
- database names are in italics
- table names are in bold italics
- column names are in bold
Keys for packages, oses, versionTypes, and variants
There are primary keys associated with the package, os, versionType, and variant tables. However, they are just used without change in the rd_releasemgr database as identifiers and are described in the write-ups on their respective tables.
buildPackageId
buildPackageId is the primary key of the buildPackage table in the rd_releasemgr database. You quest to find information about a particular build typically starts in this table. It identifies a build that is a unique combination of package, versionType, and version number.
In the entry table, which stores the logs of the builds, the buildPackageId shows up as the value in the id column in that table.
The buildPackageId value is used in the build table to link the individual builds for the various os and variant combinations associated with that package/version combination to the main buildPackage table entry.
buildId
buildId is the primary key of the build table. This is the value used by all the RM programs to work on a build and is passed in during command invocation with the --buildId flag.
In the entry table, which stores the logs of the build processes, the buildId shows up as the value in the subId column in that table.
workflowId/runId
The workflowId shows up as a column in the build table. This is the key that links the build over into the rd_workflow database. However in the rd_workflow database tables, this key is called runId. The typical first use of this key is to find the LSF output for the various processes that were run for the build in the runScripts table of the rd_workflow database.
The runId is used consistently to link all the various tables in the rd_workflow database together.
scriptId
Another column in the runScripts table is the scriptId. This is the primary key of the workflowScripts table in the rd_workflow database that lists all the possible programs that the RM can execute. This key is used consistently throughout the rd_workflow database to link all the bits and pieces about the scripts together.
jobId
jobId is a key found in the runScripts table of the rd_workflow database. This key links the entries in the rd_workflow database to entries in the rd_lsf database, specifically pointing to the job table in that database. It identifies the particular RM program + workflow id combination that was to be run by the LSF batch system. It is also used as a key in the run table of the rd_lsf database to tie the jobId to the rank key used to identify a particular LSF invocation of that piece of software (there can be more than one if the build was rerun for any reason).
rank
The rank key is used internally to the rd_lsf database to tie all the bits and pieces related to a particular LSF batch job together.
lsfId, preExecId, and callbackId
These three keys, lsfId, preExecId, and callbackId, found in the run table of the rd_lsf database, are the job IDs from the LSF batch system for the actual processes run by the batch system to execute this step of the workflow. As LSF recycles these numbers, they are only really useful if looking at very recent jobs.