OpenSolaris Source Juicer



BuildGrid Documentation
v1.0
May 2009

Components of BuildGrid

Build Master : A single system, which controls the builds.
Build Client : A physical system the is part of the build farm.
Build Zone   : A Solaris zone running on a build client. Build zones execute the 
               build jobs, one per zone.
Buildclientd : A daemon which runs on the build client and triggers jobs on that
               clients zones.
Scmsync      : A service which runs on the build master. It does the following:
                 - Creates jobs based on changes in subversion
                 - Creates cascading jobs
                 - Manages dependencies between jobs


Build Zones
-----------

The allocation of zones per client is controlled by the database. The 
buildclientd service periodically verifies the allocation of zones per client.
If the zones present on a machine are incorrect, it either creates or destroys
zones as necessary.

When creating a zone, the buildclientd service clones a zone called 'template'. 
It then configures the zone with a unique hostname and boots it up. 

A template zone is created roughly like this:

	- Create a whole root OpenSolaris zone
	- Install SUNWlang-enUS (locale problem)
	- Install Sun Studio 12
	- Install Desktop CBE & pkgbuild

The build zones have no network access for security reasons, so the buildclientd 
service must perform any network related tasks for the zone. Examples of this 
are:
	- Updating scm
	- Installing IPS packages
	- Saving log files
	- Downloading source tarballs

The build process goes something like this:
	- Reset the build zone to a ZFS snapshot taken when the zone was created
	- Update the scm needed on the zone
	- Copy the sources refrenced in the spec file to the SOURCES dir on the
	  zone
	- Install packages that are either 'Require' or 'BuildRequire' from the 
	  spec file from IPS
	- Execute the build
	- Collect the log file
	- Perform colission detection
	- Publish the package

Build Master
------------

The scmsync service on the buildmaster monitors one or more svn repositories
looking for changes. When a change is found, it:
	- Creates one build job per parent spec file, per platform which has 
	  changed or whose patches/copyright/etc. files have changed
	- Creates one build job per parent spec file, per platform which depends 
	  on the above jobs

The scmsync service scans new jobs and checks to see if this job depends on any 
other jobs. If so, it puts the job into a DEFER state until the job it depends 
on is complete.