...
Once the Qt installer is done, the mysql plugin needs to be compiled for Qt. The instructions for compiling Qt 4 MySQL drivers with MinGW are provided here http://www.jiggerjuice.net/software/qt-sql-drivers.html
Batch Submission System
...
The MySQL database for the Batch Submission System can be accessed by the rd_lsf_u user and the glastreader user. The database name is rd_lsf. The database contains the following tables
- arguments – - This table contains the arguments to be passed to the program when executing on lsf.
- callback – - This table contains the details on which state changes the upper layer should be notified.
- callbackArgs – - This table contains arguments to pass to the callback program when executing it.
- command – - This table contains the command to execute on lsf.
- job – - This table contains contains meta data, such as when it was registered, on commands to be executed on lsf.
- lsfOptions – - This table contains any options to be passed to lsf when submitting.
- output – - This table contains the output of the lsf job.
- run – - This table contains the details of a job's attempt at executing on lsf.
- settings – - This table contains global settings for the Batch Submission System.
...
The batch submission settings are controlled by a settings table with a bunch of name/value pairs. The valid names that can be specified is currently not documented anywhere except in code. The code can be viewed in CVS
The function JobSubmitter::callBsub() is the one that parses these name value pairs and creates the correct bsub command line options.
...
Each table performs a unique function as follows
- settings – - This table contains name/value pairs of settings for the workflow system.
- workflows – - This table contains a list of workflows registered.
- workflowScripts – - This table contains a list of all the scripts (aka stages) for a particular registered workflow.
- conditions – - This table lists all the conditions for a particular stage and what next stage to execute if condition evaluates to true.
- batchOpts – - This table contains a name/value pair of batch options to pas to the batch submission system for a particular stage.
- run – - This table contains the information for an actual execution of a workflow.
- runScripts – - This table contains which stage(s) are currently executing for a particular run.
- runScriptsOverride – - This table contains a few override settings of default stage settings such as which batch queue to execute.
- runSettings – - This table contains name/value pairs of settings to override for a particular run.
- runArgs – - This table contains the arguments to pass to the stages for a particular run.
- batchOptsOverride – - This table contains name/value pairs of batch options to override for a particular stage in a particular run.
...
The explanation of each of the tables is as follows
- build – - This contains the platform dependent information for a particular build.
- buildPackage – - This contains the platform independent information for a particular build.
- extLib – - This contains the external libraries used for a particular build.
- os – - This contains a list of operating systems currently supported.
- outputMessage – - This contains the checkout or compile output for a particular build.
- package – - This contains a list of checkout packages currently supported.
- settings – - This contains both global and build specific settings for the Release Manager.
- subPackage – - This contains a list of subPackages and their compile status for a particular build.
- subPackageCompileFailures – - This contains the location of specific compile failures in the compile output for a particular subPackage.
- variant – - This contains a list of supported variants.
- versionType – - This contains a list of supported versionTypes.
...
The executables and a short description of what they perform is as follows
- checkoutBuild – - This executable checks out code from cvs in preparation to building it.
- cleanBuild – - This executable erases parts of a build that are not needed for execution (source code and temporary files).
- compileBuild – - This executable builds the code checked out with checkoutBuild.
- createDoxygen – - This executable generates doxygen output for a build.
- deleteBuild – - This executable is an interactive program to trigger the RM to erase a build.
- eraseBuild – - This executable erases everything belonging to a build and marks the build as hidden in the database.
- finishBuild – - This executable marks the build as having finished.
- releaseManagerDaemon – - This executable runs in the background submitting new builds to the workflow.
- testBuild – - This executable runs the unit tests for a particular build.
- triggerBuild – - This executable can be used to trigger a new build.
- *createReleaseBuild * – - This executable creates the tar.gz/zip files of the release and externals for the installer.
...
The CMT Release Manager still expects old style tags of the form vXrYpZ so the tags above need to be converted to the old style tags. This conversion is done in two steps. First, the tagger script writes a history of tags to a file located in /nfs/slac/g/glast/ground/cvs/CVSROOT/tagHistory. The second part of this is a cron job running every minute on glastlnx14. It executes a perl script located in ~glastrm/oldStyleTagger.pl. This script reads the tagHistory file and determines what tags have occurred since the last time it ran (1 minute ago). It determines which packages where tagged with the new style tags and converts them to old style tags. It then applies these old style tags to the package. This cron job has to run as the glastrm account otherwise the two rules above that deny old style tags will apply and the tag will be denied. There's also a testOldStyleTagger.pl which is identical to oldStyleTagger.pl except for not actually executing cvs tag commands. It is used for testing out what the oldStyleTagger.pl would do for debugging purposes.
triggerBuild and deleteBuild scripts
The scripts are currently located in ~glastrm/grits-cpp/bin.
As of March 19, 2010, one must be logged in as "glastrm" to use the triggerBuild and deleteBuild scripts. An example of using deleteBuild.pl:
~glastrm/grits-cpp/bin/deleteBuild --package ScienceTools --os Windows-i386-32bit-vc71 --variant Debug --versionType Integration --version 3083