...

The workflow system has a single executable called workflowCallback. It is executed by the batch submission system when each stage starts executing and stops executing. When called for the start of the execution of a stage, it simply updates the mysql tables to indicate the start time. When executed to indicate the stop of execution of a stage, additionally it also checks the condition table to determine which, if any, other stages need to be executed. If new stages for execution are found they are submitted to the batch submission system and the cycle is repeated until a particular run has no more stages to execute.

Release Manager

Just like in the CMT version, the Release Manager consists of a few scripts that are registered in the workflow system as various stages. Conditions are setup in the workflow stages for which stages to execute next. Additionally, the Release Manager consists of several mysql tables.

Database

The Release Manager database is stored on mysql-node03. The database name is rd_releasemgr. The database contains the following tables:

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

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 os, variant, versionType, and package tables define a list of possible combinations of what the Release Manager can compile or keep track of. When new packages, oses, etc. are created they need to be inserted in these tables. Each of these tables will create automatic unique IDs that are referenced by the other tables. The settings table references both platform independent settings and platform dependent settings. The platform independent settings have NULL values for the columns that reference the os or variant tables and only include values for the package and versionType tables. The platform dependent settings have values that refer to os, variant, versionType, and package tables.

Executables

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.

The releaseManagerDaemon runs for 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 quit.

All executables take an argument of --buildId buildId. The buildId references the unique ID stored in the build table.