You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

The release manager (RM) performs the needed operations that go with code builds. It builds the code, runs unit tests and performs a myriad of functions depending on the nature of tags to various elements of the code organization. RM enforces our development environment, based on CMT checkout packages (CO). Tags of CO packages become Releases - many things happen then:

  • full documentation
  • run system tests
  • create binary distributions
  • etc as detailed below.

Modifications to the HEAD of the CO package reflects the content and testing of the next release. Tags to any constituent packages of the CO reflects the longer term release development; the collection of all "latest" tags shows what is coming down the road in these LATEST builds. RM will also do the work to create code and external library distributions on Releases (at least).

Requirements

The system discovers tags of packages in the cvs repository. For each container package being monitored, the system will

  • checkout
  • compile
  • create doxygen
  • output, link and run all available unit tests for the constituent packages.

The system will track Releases, HEAD, and (optionally) LATEST builds. It must be able to build multiple configurations of each build for each OS, including targeted compilers and optimized.

The system will submit the builds to a batch system to allow multiple builds to be performed simultaneously.

The system will store the results of the builds including the container package version, the constituent package version, the start time of the action and the completion status. It will keep logs of the builds and unit tests and make them web accessible.

Depending on what action has happened (Release, HEAD or LATEST) the system will create a a summary of the build, creating web links to release notes diffs to previous versions, to the doxygen output, cvsweb view of the particular constituent package versions and give a summary of the builds and unit tests. The system will parse the unit test logs to track the number of warnings in each compile.

The system notifies package owners in case of any failures. The system should accept interactive commands from authorized users to affect its performance, notably restarting, cleaning up failed builds and triggering specific builds.

The system will run system tests for releases. The system will create source code archives and code installers for Release builds and source code archives for HEAD builds. The locations of these archives and installers will be available from the web.

The system will check out the code to a standard location in nfs space and build all operating system configurations of the executables, storing them in the same space.

The system will keep check of available disk space and clean out old versions of builds as required.

Code and external library distributions will be automatically created using the requirements files of the particular CO package (and its constituents). The distributions should at minimum take the form of tar/zip files and minimize the binary content (ie removing duplicate binaries). The external libraries should be specific to the CO package, but could co-exist with other CO packages. Scripts will be created that do the appropriate setup to allow an end user (who is not modifying code) to not need CMT. Users should be able to fetch the files at least by ftp, and it should be clear which extlibs go with which CO package (and version).

External "actors"

  1. batch system
    1. submit jobs
    2. retrieve batch log
    3. perhaps monitor job progress
    4. be notified about job completion
  2. email notification of responsible parties about builds and problems
  3. afs & nfs space
    1. available space
    2. cleanup of old builds and related detritus
    3. archive to tape?
  4. cvs query activity (tags)
  5. user services authentication and privileges
  6. system tests - do what system tests do after being submitted for a particular configuration

Actions

  1. discover tags of tracked checkout packages
  2. checkout packages
  3. build packages
  4. run unit tests
  5. provide web access to results of 1-3
  6. parse unit test logs to record warnings count
  7. create summary of build
  8. run doxygen
  9. create diffs from last version release notes
  10. provide cvsweb view of packages
  11. notify log of build completion; notify developers of failures
  12. run system tests
  13. create source code tarballs
  14. (if so decided) create installers
  15. archive files?
  • No labels