1. GLAST Release Manager
Automated code compilation via the Release Manager
Navid Golpayegani, GSFC/SSAI
Overview
The Release Manager is a program responsible for automated builds of GLAST code. It is based on code originally written by Alex Schlessinger. It consists of three loosely connected pieces: The batch submission interface, the Workflow manager, and the Release Manager scripts. The Release Manager is currently able to run on Linux and Windows. Using a batch interface the Release Manager is able to provide feedback to developers about their code changes within two hours while still allowing for simultaneous builds. A side effect of the Release Manager is the ability for automated binary distribution of every change made to the code. An archive of each build is made available to the public via FTP as well as an installer utility developed separately.
Purpose
Language
The purpose of the Release Manager is to
Give quick feedback to developers
Automate packaging of binaries and source code for developers and end users
Provide a wrapper around the build tool of GLAST (CMT)
The Release Manager is written in Perl. It makes use of several modules available including HTML::Template. The choice of Perl has several advantages including
Quick deployment
Platform independence
Excellent shell interaction and regular expression engine
Batch Submission
Workflow
The batch submission interface is to allow simplification of the Release Manager. The scripts responsible for building will be simpler because the batch submission interface is responsible for
Keeping track jobs running in the batch farm
Notifying when a job as finished executing
Hiding the batch farm details to allow interaction with different batch farm systems
The Workflow module is a generic interface to transition from one script to another based on certain criteria. Its main purpose is to remove the logic for determining the next script to execute. This allows the scripts to perform the required task without cluttering the code with logic not necessary to its task.
Database
Scripts
The Release Manager itself consists of several simple scripts that each perform a single task. The goal of these scripts is to be simple so major problems are prevented. Each script is represented as a different state in the Workflow system. Rules are entered into the workflow system to determine which script is executed next. The scripts perform simple tasks such as:
Checking out the code from CVS
Compile the code
Run test applications on the compiled code
The Release Manager uses MySQL as its database backend. It relies on version 4 or higher due to the foreign key constraints offered by it.
User Feedback
The user is informed of the status of the Release Manager in several ways. All the builds the Release Manager is performing and past builds are available via a webpage to the user. The webpage contains detailed information about each build. The CGI applications are written in perl as well and use HTML::Template and HTML::Template::Expr heavily to separate HTML and code. All the HTML is written using XHTML 1.0 Transitional standard and validates using the W3 validator.
A second form of feedback to the user is via s. When errors are detected the Release Manager attempts to determine the Author responsible for the package causing the error. If the Author is found, an is sent to the Author notifying them of the problem. If the Author is not found an optional address can be specified where all errors are reported.
User control
Several aspects of the Release Manager can be controlled by users. The web interface provides several forms that allow the user to change information about the Release Manager. These include functions such as promoting tags and adding/removing packages. Most of these functions are restricted to logged in users and further restrictions can be applied to each logged in user.
Further, users are given permission to hide builds that are considered bad. These builds are hidden from others unless they specifically request to see them.
Finally, users are allowed to erase entire builds or parts of builds. Parts of builds that can be deleted include generated source code, documentation, build files, etc.