Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added links to pages for each of the executables

Table of Contents

Overview

Just like the CMT Release Manager, the SCons Release Manager is split into several components. These components are the batch submission system, the workflow system, and the release manager system. Unlike the CMT Release Manager, the SCons Release Manager is not written in perl. It is written in C++ relying mostly on the Qt library. Additionally, it depends on the Boost Spirit library, and the stx-exparser library. The Qt library is used for most platform independent interactions. The Boost spirit and stx-exparser are used on the linux side only for linux components only.

...

The database is stored on mysql-node03 and the database name is rd_workflow. The database contains the following tables

Code Block

+-----------------------+
| Tables_in_rd_workflow |
+-----------------------+
| batchOpts             |
| batchOptsOverride     |
| conditions            |
| run                   |
| runArgs               |
| runScripts            |
| runScriptsOverride    |
| runSettings           |
| settings              |
| workflowScripts       |
| workflows             |
+-----------------------+

...

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

Code Block

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

...

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.  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.

...