Quick tinderbox setup for FreeBSD port testing

    The proposed text is addressed primarily to FreeBSD port maintainers and the committers themselves, but even if you have not sent a single PR category ports yet, but are going to do it, or simply do not mind learning about QA methods in relation to the ports collection, then I think you too It will be interesting.

    Actually, we are talking about MarcusCom Tinderbox - a set of scripts written by Marcus Clarke and his comrades based on those used to build the official FreeBSD packages.

    In short, it works like this: you define a set of base systems (base system in FreeBSD terminology; not necessarily a release, it can be any stable branch or -CURRENT, or even your own build), port trees and builds (combinations of the first two). Then, in a pure chroot environment, you can collect any port as a package and make sure that you don’t miss anything: all dependencies are taken into account, everything is correctly assembled, installed and deleted, leaving nothing superfluous in the system. All meta-information is stored in a database (MySQL and PostgreSQL are supported), there are developed tools for updating ports and the "substrate" of the target system, caching of collected packages and distfiles, support for ccache, and even a PHP web frontend.

    Actually, installation, configuration and examples of use are described in some detail indocumentation , however, only a few use tinderbox regularly.

    Why?


    The point here, it seems to me, is that the authors were not in the first place thinking about simple developers who need nothing more complicated than just checking their port on a particular version of FreeBSD. It is not necessary to collect statistics for each port (build-logs, types of errors, the last time “everything worked”, etc.) and store it. Rarely does anyone really need web access and the tinderd service.

    In this sense, the initial requirements are unreasonably high. For, first of all, a person who wants to quickly test their changes before committing or sending PR (rather than deploying a build farm with a complete collection of statistics and then distributing it “directly to the web”) raises the question: why do I need a database at all?

    A typical FreeBSD desktop user will most likely not have any * SQL other than SQLite. Installing MySQL or PostgreSQL just for the sake of tinderbox is simply stupid for general reasons. Fortunately, more recently, the project was forked in order to improve it (the official repository has not been updated for a long time), and the first thing was added support for SQLite. For reasons unknown to me, the author deleted all his repositories on the github. You can download the catalog .git, unzip and execute the command git reset --hard. Now you can deploy tinderbox in just five to ten minutes.

    Update: SQLite support has recently appeared in the official repository .

    To the cause!


    We clone the repository into a directory with a short convenient name tband switch to the branch sqlite_support(in addition, create a link scriptsto the current directory, because we will work directly in it):

    git clone https://github.com/markjdb/tinderbox-WORK.git tb
    cd tb
    git checkout sqlite_support
    ln -s . scripts

    Immediately make a reservation that the following commands are supposed to be run from the root in order to avoid potential problems (although this is not always necessary).

    Now you need to initialize the tinderbox settings by answering a few simple questions (select sqlite as the base and set the file name):

    ./tc Setup

    The script will warn that we do not have some dependencies installed, but most of them are needed for the web frontend. We only need p5-DBD-SQLiteand lftp. If you plan to support, for example, -STABLE branches and update them using csup(1), and then collect through make world, you need to create the file tb/scripts/etc/env/GLOBALby running ./tc init, but we have enough releases that we will pick up via FTP, so this step can be skipped.

    Now we need to create what I called the substrate (in the original jails) of all versions of FreeBSD for which we want to build packages. They have nothing to do with jail(8), in this case, this is just the same name, so I did not translate it verbatim. At the core of tinderbox are onlychroot(8)and mounting by NFS or nullfs (preferable, since you do not need to configure anything). I think, for starters, we will limit ourselves to the latest releases from two stable branches:

    ./tc createJail -j 7.4 -t 7.4-RELEASE -u LFTP -H ftp.freebsd.org
    ./tc createJail -j 8.2 -t 8.2-RELEASE -u LFTP -H ftp.freebsd.org

    Names must begin with the main version number of FreeBSD (the same applies to build names, see below). The Host (option -H), it makes sense to substitute the address of the nearest mirror (we need only distsety base, dict, proflibsand src).

    Now we need to add our working ports tree - not /usr/ports, but which is checkedout from Subversion (or, in the old way, from CVS) and from where we will create diffs for send-pr(1)or commit. Let it be a directory /home/alice/fbsd/portswith the name wip(work in progress):

    ./tc createPortsTree -p wip -u NONE -m /home/alice/fbsd/ports

    The option is -u NONEnot random: we explicitly indicate that it is not necessary to update the ports tree; usually we update it ourselves through cvs^Wsvn up(after all, this is our working tree). There can be several trees, as well as substrates, but most often it is one on the machine of an ordinary ports-hacker.

    However, we are almost there. It remains to create builds: combinations of substrate and port tree. Because we have two releases (7.4 and 8.2) and one tree (wip), then there will also be two builds:

    ./tc createBuild -b 7.4-wip -j 7.4 -p wip
    ./tc createBuild -b 8.2-wip -j 8.2 -p wip

    If we did something wrong (for example, we specified incorrect parameters in one of the commands), and the record already entered the database, we will need to manually (using sqlite3 tinderbox.db) delete the corresponding records (usually from the tables jails, ports_treesor builds).

    It is logical to use the existing one as a local cache of distfiles:

    ./tc configDistfile -c /usr/ports/distfiles

    Actually, that’s all! We are ready to assemble our first package in tinderbox. Let's collect, for example, nmapfor FreeBSD-7.4 (indicating that we prefer to mount directories via nullfs and consider problems with pkg-plistfatal errors):

    ./tc tinderbuild -nullfs -plistcheck -b 7.4-wip security/nmap

    If everything is done correctly, after a while we will have new packages in the directory packages/7.4-wipand build-logs in logs/7.4-wip(if you build a port or some of its dependencies did not work out, the package will not appear, and we look for error logs in the directory errors/7.4-wipand carefully study them) :

    $ find logs packages -type f -name nmap\*
    logs/7.4-wip/nmap-5.51_2.log
    packages/7.4-wip/All/nmap-5.51_2.tbz

    In addition to files, symbolic links are also created for port categories, and so on. latest link to install the package via pkg_add -r:

    $ find packages -type l -name nmap\*
    packages/7.4-wip/Latest/nmap.tbz
    packages/7.4-wip/ipv6/nmap-5.51_2.tbz
    packages/7.4-wip/security/nmap-5.51_2.tbz

    What's next?


    In principle, usually more is not necessary; our goal is to be able to collect any ports in a clean environment for various versions of FreeBSD and not clog your system with anything superfluous. Of course, the possibilities of tinderbox are much wider, but their description is beyond the scope of the topic, and it will no longer be “configuring tinderbox in five minutes”. In addition, retelling the documentation is not good. :-)

    In conclusion, I reiterate the importance of clean assembly early on. Remember: if a port is built on your system, this does not mean that it will be collected from everyone else; only tinderbox provides assembly of what is called a pristine environment. Of course, the FreeBSD build-cluster (pointyhat) does virtually the same thing, and if the package is not built, it will be detected, the miner will receive a notification that will have to respond to, otherwise the port will be marked as BROKEN. But it all takes time, because portmgr @ has to rake in more problematic logs, and users are forced to be content with a raw product. Tinderbox, with little or no body movement on your part, if used properly, can greatly simplify the work of many people and help improve the overall quality of FreeBSD ports.

    Also popular now: