GLAST Release Manager

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
  HTMLTemplate. The choice of Perl has several
  advantages including
• Quick deployment
• Platform independence
• Excellent shell interaction and regular
  expression engine

Batch Submission
Workflow
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.

• 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

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 HTMLTemplate and HTMLTemplateExpr
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.