About
=====

This document describes a build and test framework for OpenDNSSEC based on the
idea of a version matrix that covers the major branches, i.e OpenDNSSEC-1.2,
OpenDNSSEC-1.3 and trunk.

This version matrix represents the recommended versions of software and
distributions that we support.

This document assumes that we should, as far as we can, use the versions of
required software that is supplied by the distributions.

SoftHSM will be used as an example in this document based on the small size
and few external dependencies.


Version Matrix
==============

This is just an example, please note the different distributions versions for
each major branch.

D = Distribution provided
C = Compiled

trunk          | Ubuntu 11.04   | RHEL 6.1     | FreeBSD 8.1 | SunOS 5.11
---------------|----------------|--------------|-------------|------------
         botan |Ê    1.10-1 [D] |   1.10-3 [D] |    1.10 [D] |   1.10 [C]
---------------|----------------|--------------|-------------|------------
        sqlite |    3.7.8-4 [D] |  3.7.6-5 [D] |   3.7.8 [D] |  3.7.8 [C]
---------------|----------------|--------------|-------------|------------

OpenDNSSEC-1.3 | Ubuntu 10.04.3 | RHEL 6.0     | FreeBSD 8   | SunOS 5.10
---------------|----------------|--------------|-------------|------------
         botan |Ê   1.8.6-2 [D] |   1.8.13 [C] |  1.8.11 [D] | 1.8.13 [C]
---------------|----------------|--------------|-------------|------------
        sqlite |   3.6.22-1 [D] | 3.6.20-1 [D] |   3.7.8 [D] |  3.7.8 [C]
---------------|----------------|--------------|-------------|------------

OpenDNSSEC-1.2 | Ubuntu 9.04    | RHEL 5.6     | FreeBSD 7   | SunOS 5.10
---------------|----------------|--------------|-------------|------------
         botan |Ê   1.8.3-1 [D] |    1.8.3 [C] |   1.8.3 [C] |  1.8.3 [C]
---------------|----------------|--------------|-------------|------------
        sqlite |    3.4.1-1 [D] |  3.3.9-9 [D] |   3.4.3 [D] |  3.4.3 [C]
---------------|----------------|--------------|-------------|------------


Directory Overview
==================

Every jenkins job has its own directory on each node it will be run on and
this framework also provides a common directory (fakeroot) for installing and
testing.

This common directory is set in $INSTALL_ROOT (it will be used for
--prefix=$INSTALL_ROOT) and it can easily be created by setting $INSTALL_TAG.

$INSTALL_TAG can be the major branch name i.e trunk.


Jenkins Jobs
============

With this solution there will be a set of jobs per major branch but there will
only be one build script per task.

E.i for trunk:

Job name: botan-build-trunk
  Script: INSTALL_TAG=trunk botan-build.jenkins

Job name: sqlite-build-trunk
  Script: INSTALL_TAG=trunk sqlite-build.jenkins

Job name: softhsm-build-trunk
  Script: INSTALL_TAG=trunk softhsm-build.jenkins


Managing Versions
=================

Version can be managed through a common version-matrix.jenkins file with the
layout for example like this:

SOFTWARE        DIST/VERS       DIST/VERS       DIST/VERS
TAG             VERSION         VERSION         VERSION

Ex from version matrix above:

botan           ubuntu/11.04    ubuntu/10.04.3  ubuntu/9.04     rhel/6.1
trunk           d:1.10-1        d:1.8.6-2       no              d:1.10-3
OpenDNSSEC-1.3  d:1.10-1        d:1.8.6-2       no              d:1.10-3
OpenDNSSEC-1.2  no              d:1.8.6-2       d:1.8.3-1       no

sqlite          ubuntu/11.04    ubuntu/10.04.3  ubuntu/9.04     rhel/6.1
trunk           d:3.7.8-4       d:3.6.22-1      no              d:3.7.6-5
OpenDNSSEC-1.3  d:3.7.8-4       d:3.6.22-1      no              d:3.7.6-5
OpenDNSSEC-1.2  no              d:3.6.22-1      d:3.4.1-1       no


Testing
=======

Bundled test in software (like make checks) should be run at build stage.

Other tests that we want to run will have its own jenkins job. Helpers in the
framework will set up the environment (paths and such) depending on the
INSTALL_TAG so that the test script can be generalized as much as possible.


PROs and CONs
=============

PROs:
- Each major branch has its own root
- Each jenkins job does one thing so you can quickly see what fails
- Can support different version across multiple distributions

CONs:
- Complex version matrix