ade at FreeBSD.org
Fri Dec 9 16:15:48 EST 2005
Not trying to usurp the impending release of 2.2.0, but I wouldn't
mind some feedback from others on the current (as of today) HEAD
version of tinderbox.
The HOST_WORKDIR variable allows for some pretty neat sharing of the
tinderbox infrastructure. Mine looks something like this:
central machine, running mysql/pgsql and the webui, also containing
an NFS-exported /tbox tree where jail tarballs, and packages and
associated errorlogs and logfiles are kept.
3 builder boxes, as follows:
central:/tbox -> /tbox
/local (a largish UFS local filesystem)
by setting HOST_WORKDIR to /local, three things happen:
1. jails are built on the local UFS filesystem, with the tarballs
being written back to the NFS /tbox/jails/.../ directory
2. tinderbuilds are also run on the local UFS filesystem, with the
packages being written back to the packages, logs and errors
directory on the central host after building. Note that if you're
using portstrees directly from the NFS filesystem, you *have* to use
the -nullfs option to tinderbuild (since NFS mounts of an NFS mounted
directory don't work)
3. the ccache directory (either per-jail, or per-build) is also run
on the per-machine local filesystem.
The major benefits so far are (a) no more maze of symlinks as
required prior to these changes and (b) the ability to run a single
webUI instance handling multiple backend builder boxes.
The next step is to write out the pseudo-schema and code for actual
distributed building (this will be provided in addition to the
standard 'tc tinderbuild' scheme), but I'd like for others to test
out what I have now before getting into that.
More information about the tinderbox-list