Difference between revisions of "Building in Docker"

From DUNE
Jump to navigation Jump to search
Line 11: Line 11:
 
The problem being solved here is how to describe and populate a <b>build space</b>.  Here, a build space is a (binary) scalar field across a discrete, multi-dimensional space with the following axes:
 
The problem being solved here is how to describe and populate a <b>build space</b>.  Here, a build space is a (binary) scalar field across a discrete, multi-dimensional space with the following axes:
  
; platforms : Identified by a pair of (name,version) which gives the distribution name (Debian, Ubuntu, Fedora, Scientific, Mac OS X) plus its version.
+
; platforms : A <b>platform</b> is specified by its distribution name (Debian, Ubuntu, Fedora, Scientific, Mac OS X) its release version string and a set of additional OS-level packages.
; releases : the release of the LBNE software and identified by a git tag on {{gh|repo=lbne-build}}.
 
; prerequisites : the list of software packages required by a given release but not provided as part of the base platform.  This list is largely constant but is weakly dependent on both the platform and the release.  Each "tick" on this axis is one unique set of packages and conceptually we ignore the fact that each distribution "spells" their names differently.
 
; environment : this includes peculiarities about the environment in which the build is run which is independent from the above.  In particular it includes any LAN-specific things like the need to account for explicit HTTP/FTP proxies
 
  
The binary scalar value of this space is then either "true" if its combination is supported for "false" if not.  This scalar field and the extent of the space changes over time as new platforms are created, new software releases are made, etc, and their support is added or removed.
+
; releases : A <b>release</b> is specified by a git tag, hash or other ref on {{gh|repo=lbne-build}}.
 +
 
 +
; environment : The <b>environment> includes any peculiarities about the environment in which the build is run which is independent from the above. For example, the need to deal with network proxies.
 +
 
 +
The binary scalar value of this space is then either "true" if its combination is supported for "false" if not.  This scalar field (and the defined extent of the space) changes over time as new platforms are created, new software releases are made, new build environments are added and their combined support is added or removed.

Revision as of 18:32, 30 December 2014

Overview

The Software Builds can be done with and in Docker containers using lbne-docker . See the README file there for details.

Note: This method is under development.

Build Space

This is a bit tongue-in-cheek but describes the problem in general terms.

The problem being solved here is how to describe and populate a build space. Here, a build space is a (binary) scalar field across a discrete, multi-dimensional space with the following axes:

platforms 
A platform is specified by its distribution name (Debian, Ubuntu, Fedora, Scientific, Mac OS X) its release version string and a set of additional OS-level packages.
releases 
A release is specified by a git tag, hash or other ref on lbne-build .
environment 
The environment> includes any peculiarities about the environment in which the build is run which is independent from the above. For example, the need to deal with network proxies.

The binary scalar value of this space is then either "true" if its combination is supported for "false" if not. This scalar field (and the defined extent of the space) changes over time as new platforms are created, new software releases are made, new build environments are added and their combined support is added or removed.