OpenSolaris build service proposal

With most open source projects the various pieces are relatively small and as a result, the build process for any component is measured in seconds or minutes. Solaris has historically been based upon consolidations - relatively large sets of code. The most common wrapper around the build process is called nightly for good reason - it takes hours to days to perform a full build. Once a full build is complete incrementals can take a lot less time, but if you infrequently build the software, you are pretty much forced into a full build every time. I just stumbled across this post that shows that others have noticed this problem too.

What can be done?

I've been thinking that most people really don't need a full clobber build all the time. If there is a 2 line fix somewhere, just verifying that the code builds and the resulting binaries work is most important - and most encouraging for the casual bug fixer. If there's a big re-work of Makefiles or changes are made to the linking of a program a full build may be more important. A service that can do incremental builds would be a big help.

So here's (very roughly) how I envision it.

Each time a release is tagged by a participating consolidation...

1. A job is kicked off to build it on each supported architecture.
2. A zfs snapshot is created of the workspace with the completed build.
3. The completed build is packaged into an IPS repository

When a developer wants to fix a bug...

1. Populate a workspace with the original source code
2. Hack
3. Create a webrev
4. Submit the webrev to the build system, saying which consolidation and build to build against and which architectures to build for

The build system then...

1. Schedules the job via Hudson or Grid Engine.
2. The job starts by cloning the pre-built release of the consolidation. Quite likely, it also clones then boots the proper boot environment.
3. The patch included in the webrev is applied to the source
4. An incremental build is done
5. The pre-built IPS repository is cloned to a per-developer repository
6. Packages associated with the changed files are populated into the per-developer IPS repository. The changed packages associated with this build are added as dependencies to a special package (e.g. build-20080611.0)
7. Results are sent to the developer.

In most cases, the execution time of the above could be just a few minutes. If the change triggers lots of dependencies, it could be many hours. To test the changes, the developer can use...

beadm create testbe
beadm mount testbe /testbe
pkg -R /testbe set-authority -O http://pkg.opensolaris.org/mysername myusername.opensolaris.org
pkg -R /testbe install build-20080611.0
beadm unmount testbe
beadm activate testbe
init 6

There are certainly plenty of details to work out. This is meant to be the start of a discussion to determine wether it is something worth pursuing and if so what those missing details are.