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 emails. 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 email is sent to the Author notifying them of the problem. If the Author is not found an optional email 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.