# -*- perl -*- # # Test::AutoBuild by Dan Berrange, Richard Jones # # Copyright (C) 2002 Dan Berrange, Richard Jones # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # $Id: AutoBuild.pm,v 1.46 2006/08/21 03:57:07 danpb Exp $ =pod =head1 NAME Test::AutoBuild - Automated build engine controller =head1 SYNOPSIS use Test::AutoBuild; use Config::Record; my $config = new Config::Record (file => $filename); my $builder = new Test::AutoBuild (config => $config); my ($status, $log) = $builder->run($timestamp); if ($status) { print STDERR $log, "\n"; } exit $status; =head1 DESCRIPTION This module provides the build controller, tieing together various subsystems to form an integrated engine. It is wholely reponsible for loading the various runtime objects (stages, modules, repositories, package types, monitors, publishers) based on their definitions in the configuration file and then invoking the build. This object does not, however, contain any logic pertaining to how the build is run, since this is all delegated to the stages defined in the configuration file. =head1 SETUP After installing the modules, the first setup step is to create an unprivileged user to run the build as. By convention the user is called 'builder', in a similarly named group and a home directory of /var/lib/builder. So as root, execute the following commands: $ groupadd builder $ useradd -g builder -m -d /var/lib/builder builder NB, with the combined contents of the source checkout, the cache and the virtual installed root, and HTTP site, the disk space requirements can be pretty large for any non-trivial software. Based on the applications being built, anywhere between 100MB and many GB of disk space make be neccessary. For Linux, making /var/lib/builder a dedicated partition with LVM (Logical Volume Manager) will enable additional space to be easily grafted on without requiring a re-build. The next step is to create the basic directory structure within the user's home directory for storing the various files. There are directories required for storing the source code, a virtual root directory for installing files, a build archive, package spool directories, and publishing directories for HTTP and FTP servers. To facilitate quick setup, a script is provided to create all the required directories. Run this script as the unprivileged user $ su - builder $ auto-build-make-root /var/lib/builder It will display a list of all the directories it creates, but for advance reference, they are /var/lib/builder/install-root /var/lib/builder/source-root /var/lib/builder/log-root /var/lib/builder/build-archive /var/lib/builder/package-root /var/lib/builder/package-root/rpm /var/lib/builder/package-root/rpm/BUILD /var/lib/builder/package-root/rpm/RPMS /var/lib/builder/package-root/rpm/RPMS/noarch /var/lib/builder/package-root/rpm/RPMS/i386 /var/lib/builder/package-root/rpm/RPMS/i486 /var/lib/builder/package-root/rpm/RPMS/i586 /var/lib/builder/package-root/rpm/RPMS/i686 /var/lib/builder/package-root/rpm/RPMS/x86_64 /var/lib/builder/package-root/rpm/RPMS/ia32e /var/lib/builder/package-root/rpm/RPMS/ia64 /var/lib/builder/package-root/rpm/RPMS/sparc /var/lib/builder/package-root/rpm/SPECS /var/lib/builder/package-root/rpm/SOURCES /var/lib/builder/package-root/rpm/SRPMS /var/lib/builder/package-root/zips /var/lib/builder/package-root/tars /var/lib/builder/package-root/debian =head1 CONFIGURATION The configuration file determines all aspects of operation of the build engine, from the modules built, through the package types detected, archival method, to build workflow stages, and much more. The example build configuration file installed by default should provide a fully functional build instance running under /var/lib/builder, which is capable of building Test-AutoBuild, versions 1.0.x and 1.1.x, along with the AutoBuild-Applet. A good sanity check for correct installation, is to ensure that the example build configuration succeeds when run. The configuration file is split into a number of logical groups, which will be considered in turn below. The minimal level of configuration to get started involves editing the list of modules, along with the source repository definitions. =head2 General runtime The following options define miscellaneous aspects of the build engine runtime environment. =over 4 =item root The C option is a grouping under which core directories of the build engine are defined. root = { ... nested options... } The following nested options are permitted with the C option =over 4 =item source The location into which modules' source code will be checked out from version control. If not specified this option defaults to the location $HOME/source-root root = { ... source = /var/lib/builder/source-root ... } Thus, a module with a name of 'dbus-dev' would be checked out into the directory /var/lib/builder/source-root/dbus-dev =item install The location into which a module's build process would install files to be used by dependant modules later in the build cycle. This location is made available to a module's build control file via the environment variable $AUTOBUILD_INSTALL_ROOT. If not specified this option defaults to the location $HOME/install-root root = { ... install = /var/lib/builder/install-root ... } Consider, for example, a module 'mozilla' which depends on a library 'openssl'. The 'openssl' module would be listed as a dependant module so that it is built first. The build of 'openssl' would install itself into the install root, perhaps by passing the 'prefix' argument to a configure script: ./configure --prefix=$AUTOBUILD_INSTALL_ROOT The later build of mozilla, would then build against this version of openssl, by using ./configure --with-openssl=$AUTOBUILD_INSTALL_ROOT =item package The location in which a module's build process will create any binary packages it generates, for example RPMs, or Debian packages. The packages are typically placed into a package type specific sub-directory. This location is made available to a module's build control file via the environment variable $AUTOBUILD_PACKAGE_ROOT. If not specified, this option defaults to the location $HOME/package-root root = { ... package = /var/lib/builder/package-root ... } Consider, for example, a module which generates an RPM, of itself. The $AUTOBUILD_PACKAGE_ROOT directory would be used to set the '_topdir' macro for the RPM build process rpmbuild --define '_topdir $AUTOBUILD_PACKAGE_ROOT/rpm' -ta foo.tar.gz =item log The location in which the output from a module's build control file will be spooled during execution. If not specified, this option defaults to the location $HOME/log-root. The control file's standard output and error streams will be combined into one. root = { ... log = /var/lib/builder/log-root ... } =back =item admin-email The email address of the build engine administrator, typically linked from the bottom of the HTML status pages. This is also the address spammed with build status alerts if the L module is in use. admin-email = admin@example.com =item admin-name The full name of the build engine administrator, typically displayed on the bottom of the HTML status pages. admin-name = John Doe =item log4perl A configuration block controlling the output of debug information during execution of the build. The data here is passed straight through to the C method in the L module, so consult that module's manual page for possible configuration options. The example setting, enables display of progress through the build workflow. To get maximum possible debug information, change the C option to 'DEBUG' instead of 'WARN'. log4perl = { log4perl.rootLogger = WARN, Screen # To get progress updates log4perl.logger.Test.AutoBuild.Monitor.Log4perl = INFO log4perl.appender.Screen = Log::Log4perl::Appender::Screen log4perl.appender.Screen.stderr = 1 log4perl.appender.Screen.layout = Log::Log4perl::Layout::SimpleLayout } =item counter This configuration block determines the module used to generate the unique build cycle counter. counter = { ..nested options.. } The nested options allowed within this block are =over 4 =item module The full package name of the subclass of L used to generate the build cycle counter. Consult that module for a list of known implementations. The exmaple configuration sets the build counter to match the timestamp taken at the start of the build cycle. module = Test::AutoBuild::Counter::Timestamp =item options This is defines a set of options as key, value pairs which are passed to the counter object created. The valid keys for this are specific to the package specified in the C parameter above, so consult the manual page corresponding to the module defined there. If using the C class, and there is a source repository named, C, one would set an option such as options = { repository = mysvn } =back =back =head2 Source repositories The C configuration block, defines the source repositories from which modules are checked out. The keys in the block form the short name of the repository, and is referenced later when defining the paths for modules' source checkout repositories = { myrepo = { ... definition of myrepo ... } otherrepo = { ... definition of otherrepo ... } } Within each repository definition the following options are supported =over 4 =item label The free-text display name of the repository, typically used in the HTML status pages. =item module The full package name of a subclass of C which implements the checkout procedure for the repository type. There are repository types for common version control systems such as Subversion, CVS, Perforce and GNUArch, as well as a simple non-versioned repository. Refer to the L module for a list of known repository types and their corresponding package names. module = Test::AutoBuild::Repository::Subversion =item env Lists a set of environment variables which will be set whenever running any repository commands. The possible environment variable names vary according to the type of repository, so refer to the manual page for the repository module defined in the C option. For example, the CVS repository type uses the CVSROOT environment variable to specify the repository location. env = { CVSROOT = :pserver:nonymous@cvs.gna.org:/cvs/testautobuild } =item option A set of configuration options specific to the type of repository configure. Again, refer to the manual page for the repository module defined in the C option. For example, the GNU Arch repository type supports the 'archive-name' option options = { archive-name = lord@emf.net--2004 } =back =head2 Modules The C configuration block defines the list of modules to be checked out of source control and built. The keys in the block form the short names for the modules, used, for example, in creating filenames for assets relating to the module, and the name of the checkout directory under the source root. If building multiple branches of a module, it is common to post-fix the module name with a version / branch name. modules = { mymod-1.0 = { .. definition of mymod version 1.0.. } mymod-dev = { .. definition of mymod development snapshot... } } Within the configuration block of an individual module the following options are permitted =over 4 =item label The free-text display name for the module, typically used in HTML status pages, and email alerts. label = Test-AutoBuild (Development branch) =item source This block defines the repository containing the source to be checked out for the module. There are two keys in the block, the value associated with the key C, is the name of a repository previously defined in the config file. The value associated with the key C is the path to checkout within the repository. The syntax for path values is dependant on the type of repository being accessed. For details refer to the manual pages for the corresponding modules: =over 4 =item CVS Refer to L =item GNU Arch Refer to L =item Subversion Refer to L =item Perforce Refer to L =item Mercurial Refer to L =item SVK Refer to L =item Local disk Refer to L =back An example config entry for a module checked out of CVS is source = { repository = gna-cvs path = /testautobuild } =item sources If a module's source is split amongst several locations, this block is used instead of the C block. It allows defintion of a list of source paths to checkout. It is a list, where each entry matches the format of the C parameter. For example sources = ( { repository = gna-cvs path = /testautobuild } { repository = local-disk path = /testautobuild-autobuild.sh -> autobuild.sh } ) NB, not all repository types play nicely together when checking out from multiple paths. Consult manual pages for individual repository types for futher information =item groups Lists the groups to which the module belongs. The values in the list must be group names, specified earlier in the top level C configuration block. groups = ( software perl ) =item env Defines a set of environment variables which will be set whenever running the build/test control files for the module. The only restriction on variables set here, are that none should be named with the prefix AUTOBUILD_, otherwise they are liable to be overridden by variables set by the build engine. env = ( SKIP_TESTS = 1 ) =item options The options parameter is used to specify module specific data which will be used by stages in the workflow engine. Consult the manual pages for individual stages in use, for further details on which options are possible. The most common option is C which can be used to override the default name of the command to invoke to run the build. For compatability with version 1.0.x of autobuild, this should be set to 'rollingbuild.sh' options = { control-file = rollingbuild.sh } =item links The links configuration block defines a simple list of hyperlinks relating to the module. This is typically used to provide links to a graphical front end for the source repository, or a link to a project homepage. The two keys with the block are C and C