tinderbox


I run a build bot to identify static build + installation issues of Gentoo Linux software packages*.

Up to 10 chroot images are running in parallel at a dedicated server. Each image is set up from a recent stage3 tarball as an arbitrary combination of (~)amd64 + profile + USE flag set.

Within each image a fair amount of all packages of the main Gentoo tree are tried to be emerged in a randomized order. Once a day @system and @world are updated. No parallel emerge, no parallel make, no unmerge and no depclean is made. The repository is synced hourly at the host system via Git and shared to each chroot image via bind mount. Recent tree changes are mixed into the backlog of each image.

700 packages per image are emerged daily, 2% do fail (6% with FEATURES=test). An image is replaced by a fresh new one usually after 12 days (based on this lifetime model). The coverage of the repository is about 98% after 12 days with 9 running images. The old image is kept around for 2 months.

Github holds the source code (GNU GPL v3).

The Portage File List is fed too.

*just to have fun, and to redeem to a Linux distribution I do use and trust since 2003. The Gentoo project has its own tinderbox cluster with a slightly different approach.


tl;dr;
The tinderbox runs in each chroot: "qsearch --all | sort --random-sort | xargs -n 1 emerge --update" and just parses the output.


back to my home page