| Table of Contents |
|---|
This section concerns only the code under grits-cpp/ReleaseManager releaseManager and the databases it talks to.
...
- Automatically make ("HEAD") builds for configured OSes when a new release candidate tag is created
- Automatically make ("Release") builds for configured OSes when a new release tag is created
- Automatically make ("LATEST") builds for configured OSes when a new subpackage tag is created
where "making a build" means
- fresh checkout of proper version of code from repository
- compilation, creating libraries and executables (SCons)
- also copy externals used to Installer location if not already there
- creation of tarballs for distribution (SCons)
- running package test programs
- creating Doxygen output
- notifying package owners of failures
Among the RM code are executables with names like "checkoutBuild", "createDoxygen", etc. Each of the steps above involves calling such a program. For those steps labeled (SCons) the bulk of the work is done by invoking SCons.
Results of various kinds are saved for later retrieval and display.
Manual functions
The functions above invoke various executables to accomplish their tasks. These executables may be invoked by hand if, for example, some part of the build output needs to be generated or regenerated. The RM code also includes some additional executables which may be invoked manually. Typical tasks which one might want to do manually include
...
- rd_lsf is used for interactions with the lsf batch system.
- rd_workflow is used to properly sequence jobs needed for a particular operation. For Jenkins workflows there is just one entry describing the launch of a Jenkins job; the details (first checkout code, then build, etc.) are handled elsewhere. For OSes not directed to Jenkins, there are entries in the workflow db describing what has to happen and what steps any given step depends upon.
- rd_releaseMgr releasemgr is by far the most complex of the three. It contains all the information needed to configure builds by os, container (ST, GR, etc.), build type (Release, Release candidate, LATEST) and variant (Debug, Opt) and also information about the status of particular builds (by os, container, build type and tag version).
...
In addition to the core functions described above, there are several others which depend to some degree on RM being constituted more or less as it currently is. For the most part this boils down to a dependence on one or both of the rd_releaseMgr database and tagging conventions.
Release Manager results on the Web
Information displayed comes from RM database
Installers
Information needed to satisfy clients comes from RM database. Build products transported to client are created by RM.
Tagging
The only tags RM creates are for LATEST builds (use most recent tag for each subpackage), but RM expects both package tags and container-wide tags to be of a certain form. We currently have a tool (C++ program to help users create subpackage tags of the proper form and another (Python script) one for creating container-wide tags for releases and release candidates. We'll need something for the equivalent tasks which talk to git rather than CVS. (Assuming we don't change the required tag form these tools have nothing directly to do with the fate of RM; it's driven by the move to git.)