ReleaseEngineering/PuppetAgain/Modules/buildslave

This module installs and sets up the buildslave software. Including buildslave will do both.

Requirability

The buildslave class can be required, if necessary:

 require => Class['buildslave']

Embedded Classes

buildslave::install

This class installs the buildbot and buildbot-slave packages in a virtualenv keyed from the version number, with a symlink at /tools/buildbot denoting the active version. This class embodies the intelligence of what version(s) of Buildbot to install.

Internally, it uses buildslave::install::version to install the correct versions, e.g.,

 buildslave::install::version {
     "0.8.4":
         active => false;
     "0.8.5":
         active => true;
 }

This nested class takes an ensure parameter (absent or present) and an active parameter, which if true causes the /tools/buildbot symlink to point to the given version.

Upgrading

To add a new version of buildbot slave. Please note that in order to deploy a new version of the slave, a new package for the master is needed as well in order for the slave to be able to send sendchanges to the master. Puppet will fail if only the buildbot-slave package is built.

• establish the desired version of the buildbot source, on the 'slaves' branch of build/buildbot
• tag it with SLAVE_X_Y_Z_MOZN as appropriate
• add slave/buildslave/VERSION containing the lower-case form, e.g., 3.4.1-moz3. similarly for master/buildslave/VERSION
• run 'setup.py sdist' in the slave/ directory and in the master/ directory
• copy the resulting {master,slave}/dist/buildbot-*.tar.gz into the python-packages directory (see ReleaseEngineering/PuppetAgain/Python)
• add a new case to modules/buildslave/manifests/install/version.pp setting any relevant variables for the install.
• invoke the new case from modules/buildslave/manifests/install.pp

Make sure to use the "slaves" branch: different branches for masters and slaves were created when we upgraded the buildslaves without upgrading the buildmaster, which also happened to be while we were still running some 0.7 masters. The remaining masters are all built from the production-0.8 branch, while slaves are built from the slave branch.

The distutils version to be used to build the packages must be 2.7.2 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1009584). You can check the distutils version installed in your system as follows:

   $ python
   Python 2.7.2 (default, Oct 11 2012, 20:14:37)
   [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import distutils
   >>> distutils.__version__
   '2.7.2'

buildslave::startup

This class makes sure that the buildslave will start up appropriately. This class supports a number of different startup techniques:

• initd -- a linux initscript which runs after puppet, and which invokes runslave.py in the proper context
• launchd -- an OS X launchd plist which runs as the logged-in user (hopefully the builder user), and does not start until a sentinel file is touched by the puppet startup script, indicating it is complete.

See ReleaseEngineering/Buildslave_Startup_Process for more details on the startup process.