Быстрая настройка tinderbox для тестирования портов FreeBSD

Предлагаемый текст адресован в первую очередь майнтейнерам портов FreeBSD и собственно коммитерам, но даже если вы пока не посылали ни одного PR категории ports, но собираетесь это сделать, или же просто не прочь узнать о методах QA применительно к коллекции портов, то думаю, вам тоже будет небезынтересно.

Собственно, речь идет о MarcusCom Tinderbox — наборе скриптов, написанных Маркусом Кларком сотоварищи на основе тех, что используются для сборки официальных пакетов FreeBSD.

Вкратце, работает это так: вы задаете набор базовых систем (base system в терминологии FreeBSD; не обязательно релиз, это может быть любая стабильная ветка или -CURRENT, или даже ваша собственная сборка), деревьев портов и билдов (комбинаций из первых двух). Затем в чистом chroot-окружении вы можете собрать любой порт как пакет, и убедиться, что ничего не пропустили: все зависимости учтены, все корректно собирается, ставится и удаляется, не оставляя ничего лишнего после себя в системе. Вся метаинформация хранится в базе данных (поддерживаются MySQL и PostgreSQL), есть развитые средства обновления портов и «субстрата» целевой системы, кэширование собранных пакетов и дистфайлов, поддержка ccache и даже web-фронтенд на PHP.

Собственно, установка, настройка и примеры использования довольно подробно описаны в документации, однако регулярно пользуются tinderbox лишь немногие.

Почему?

Дело тут, мне кажется, в том, что авторы далеко не в первую очередь думали о простых разработчиках, которым не требуется ничего сложнее, чем просто проверить свой порт на той или иной версии FreeBSD. Не надо собирать статистику по каждому порту (build-логи, типы ошибок, когда последний раз «все работало», etc.) и хранить ее. Редко кому действительно необходим веб-доступ и сервис tinderd.

В этом смысле начальные требования необоснованно завышены. Ибо в первую очередь у человека, которому хочется быстро протестировать свои изменения перед коммитом или отправкой PR (а не разворачивать build farm с полным сбором статистики и последующей ее раздачей «прямо в веб») возникает вопрос: а зачем мне вообще база данных-то?

У типичного пользователя FreeBSD на десктопе, скорее всего, не будет никакого *SQL кроме SQLite. Ставить MySQL или PostgreSQL только ради tinderbox просто глупо из общих соображений. К счастью, совсем недавно проект был форкнут с целью его улучшения (официальный репозиторий давно не обновлялся), и первым делом была добавлена поддержка SQLite. По неизвестной мне причине автор удалил все свои репозитории на гитхабе. Вы можете скачать каталог .git, распаковать и выполнить команду git reset --hard. Теперь развернуть tinderbox можно буквально за пять-десять минут.

Update: с недавнего времени поддержка SQLite появилась и в официальном репозитории.

За дело!

Клонируем репозиторий в каталог с коротким удобным названием tb и переключаемся на ветку sqlite_support (кроме того, создадим ссылку scripts на текущий каталог, т.к. мы будем работать непосредственно в нем):

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

Сразу оговорюсь, что нижеследующие команды предполагается выполнять из-под рута во избежание потенциальных проблем (хотя это не всегда обязательно).

Теперь нужно проинициализировать настройки tinderbox, ответив на несколько простых вопросов (выбираем в качестве базы sqlite и задаем имя файла):

./tc Setup

Скрипт предупредит, что у нас не установлены некоторые зависимости, но большинство из них нужны для web-фронтенда. Нам же понадобятся только p5-DBD-SQLite и lftp. Если вы планируете поддерживать, например, -STABLE ветки и обновлять их при помощи csup(1), а затем собирать через make world, нужно создать файл tb/scripts/etc/env/GLOBAL, запустив ./tc init, но нам достаточно релизов, которые мы будем забирать по FTP, так что этот шаг можно пропустить.

Теперь надо создать то, что я выше назвал субстратом (в оригинале jails) всех версий FreeBSD, для которых мы хотим собирать пакеты. Они не имеют никакого отношения к jail(8), в данном случае это всего лишь совпадающее название, поэтому я не стал переводить его дословно. В основе tinderbox лежат только chroot(8) и монтирование по NFS или nullfs (предпочтительнее, так как не надо ничего настраивать). Думаю, для начала ограничимся последними релизами из двух стабильных веток:

./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

Имена должны начинаться с главного номера версии FreeBSD (это же касается и имен билдов, см. ниже). В качестве хоста (параметр -H) имеет смысл подставить адрес ближайшего зеркала (нам потребуются только дистсеты base, dict, proflibs и src).

Теперь надо добавить наше рабочее дерево портов — не /usr/ports, а которое checkout'нуто из Subversion (или, по-старинке, из CVS) и откуда мы будем создавать diff'ы для send-pr(1) или коммитить. Пусть это будет каталог /home/alice/fbsd/ports с названием wip (work in progress):

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

Опция -u NONE не случайна: мы явно указываем, что обновлять дерево портов не нужно; обычно мы обновляем его сами через cvs^Wsvn up (ведь это наше рабочее дерево). Деревьев, как и субстратов, может быть несколько, но чаще всего на машине рядового ports-хакера оно одно.

Однако, мы почти у цели. Осталось насоздавать билдов (builds): комбинаций из субстрата и дерева портов. Т.к. у нас два релиза (7.4 и 8.2) и одно дерево (wip), то билда тоже будет два:

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

Если мы что-то сделали не так (например, указали неверные параметры в какой-то из команд), а запись в базу уже попала, нужно будет вручную (с помощью sqlite3 tinderbox.db) удалить соответствующие записи (обычно из таблиц jails, ports_trees или builds).

В качестве локального кэша дистфайлов логично использовать уже имеющийся:

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

Собственно, все! Мы готовы собрать наш первый пакет в tinderbox. Соберем, например, nmap для FreeBSD-7.4 (указав, что предпочитаем монтировать каталоги через nullfs и считать проблемы с pkg-plist фатальными ошибками):

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

Если все сделано правильно, спустя некоторое время у нас появятся новые пакеты в каталоге packages/7.4-wip и build-логи в logs/7.4-wip (если собрать порт или какую-либо из его зависимостей не получилось, то пакет не появится, а логи ошибок ищем в каталоге errors/7.4-wip и внимательно их изучаем):

$ 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

Кроме файлов, также создаются символические ссылки по категориям порта и т.н. latest link для установки пакета через 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

Что дальше?

В принципе, обычно большего и не надо; наша цель — уметь собирать любые порты в чистом окружении для различных версий FreeBSD и не засорять при этом свою систему ничем лишним. Конечно, возможности tinderbox гораздо шире, но их описание выходит за рамки топика, и это уже не будет «настраиваем tinderbox за пять минут». К тому же, пересказывать документацию нехорошо. :-)

В заключение я еще раз подчеркну важность чистой сборки на раннем этапе. Помните: если порт собирается на вашей системе, это еще не означает, что он соберется у всех остальных; только tinderbox обеспечивает сборку, что называется, в pristine environment. Конечно, build-кластер FreeBSD (pointyhat) делает фактически то же самое, и если пакет не собирается, то это будет выявлено, майнтейнер получит уведомление, на которое должен будет отреагировать, иначе порт пометят как BROKEN. Но на это все уходит время, т.к. portmgr@ приходится разгребать больше проблемных логов, а пользователи вынуждены довольствоваться сырым продуктом. Tinderbox, почти не требуя телодвижений с вашей стороны, при правильном использовании может сильно упростить труд многих людей и помочь повысить общее качество портов FreeBSD.