...

The Batch Submission System consists of two applications. The lsf Daemon and the lsf callback application. The daemon is setup to run on fermilnx-v03 (a virtual machine) via trscron (trscron is used instead of regular cron because the LSF processes need AFS tokens and normal cron doesn't provide them). The daemon runs for an hour and is then retriggered.

glastlnx20 via trscron. It checks the database for new jobs. Jobs are submitted to lsf in suspend mode. For each job, there are three lsf tasks submitted. The first tasks is the actual command to be executed. The second task is a call to lsf callback application with the condition that it be executed as soon as the first task starts execution. The third task is a call to lsf callback application with the condition that it be executed as soon as the first task finishes execution. All lsf tasks are submitted and initially put into suspend mode. If all three tasks are submitted successfully, the jobs are changed from suspend to pending mode so they actually start execution. If at any time anything goes wrong, the lsf tasks are killed and the run in the table is marked as failed. The job is put back into the queue to be attempted at a later time as a new run.

...

+---------------------------+
| Tables_in_rd_releasemgr   |
+---------------------------+
| build                     |
| buildPackage              |
| entry extLib                    |
| os   extLib                     |
| outputMessageos             |
| package          |
| outputMessage             |
| package                   |
| settings                  |
| subPackage                |
| subPackageCompileFailures |
| variant                   |
| versionType               |
+---------------------------+

...

• 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.
• entry - this table was migraged from glastdb and hold the log entries from the operation of all the RM processes.  Logs are kept for 5 days and then removed to prevent the database from filling up.
• 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.

...

• 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.  By default, the entry will remain in the database.
  ex. deleteBuild --package ScienceTools --versionType Integration --version 3366 --os Windows-i386-32bit-vc90 --variant Debug --complete
  versionType may be Integration "Release Candidate", or Release
  The --complete option erases the build and also removes the entry from the database.  This is used when one wishes to re-trigger a build.
• eraseBuild – This executable erases everything belonging to a build and marks the build as hidden in the database.  This is called by deleteBuild and most likely never need be called directly by a user.  As this is the program called by deleteBuild to actually do the remove, it also supports the --complete option.
• 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 releaseManagerDaemon runs for 6 hours on fermilnx-v03 before shutting down.  A cron job on fermilnx-v03 restarts the process every 6 hours.  Regular cron is used as no AFS tokens are needed for this daemon and the use of trscron (changing the trscrontab entries) requires the glastrm account to have a password which the system administrators would rather not have.  The process used to run for 24 hours but changes to the MySQL database backend resulted in timeouts after 8 hours so the run period was shortened to accommodate this issue.

While running, 24 hours on glastlnx20. In that period it checks for new builds to submit to the workflow based on the rules specified in the settings tables. It is capable of submitting builds for all the combinations that are allowed by the os, variant, versionType, and package tables as long as appropriate settings exist in the settings table. This daemon is started up by trscrontab as the glastrm user on glastlnx20 every 24 hours shortly after the previous instance has quitas appropriate settings exist in the settings table.

All executables take an argument of --buildId buildId. The buildId references the unique ID stored in the build table. These executables are in /u/gl/glastrm/grits-cpp/bin on slac linux.

...

The Release Manager notifies users of failures when executing the finishBuild executable. Similar to the CMT RM, the finishBuild executable checks the database for any registered failures and looks up the author's information in the package SConscript file. Unlike the CMT RM, the finishBuild executable attempts to bundle as many failures together for a particular author as it can. The goal is to only send a single email per build to a person for all the packages that belong to the author which contain errors.

Old Style Tagger

With the shut down of automated CMT builds, the old style tagger has also been shut off (June 2013) and its use is now deprecated.  However, the material is kept here for reference.

The CVS repository is currently set to deny any tags that do not conform to the format packageName-XX-YY-ZZ when the following rules apply:

...