Пакетное тестирование с Buildbot и KVM

Тестирование пакетов MariaDB с помощью Buildbot

Эта часть настройки Buildbot использует виртуальные машины KVM для сборки пакетов на широком спектре дистрибутивов Linux и тестирования различных пакетов различными способами.

Сборка выполняется на одном хосте, который имеет процессор Intel Core i7 860 @ 2.80 ГГц, 8 ГБ оперативной памяти и диск ёмкостью 500 ГБ. На хосте сборки установлена Ubuntu 9.04 Server 64-bit. Текущая машина способна выполнять до 3 сборок параллельно. Весь набор из 19 сборок занимает около 3,5 часов.

Хост сборки не содержит виртуальных машин, которые остаются запущенными в режиме ожидания. Вместо этого каждая сборка запускает и останавливает виртуальные машины по мере необходимости, используя инструмент runvm.

Подробности настройки (установки) виртуальных машин находятся здесь.

Сборки

(Пожалуйста, проверьте конфигурацию Buildbot на предмет деталей, на случай если эта информация устареет).

На момент написания выполняются следующие сборки:

• Сборка исходного tar-архива (на виртуальной машине Ubuntu 9.04 32-битной версии)
• Бинарные tar-архивы, i386 и amd64, на виртуальных машинах Ubuntu 8.04.
• Ubuntu, i386 и amd64: 8.04, 8.10, 9.04, 9.10, 10.04 (альфа).
• Debian, i386 и amd64, Debian 4 и Debian 5.
• Centos 5, i386 и amd64.

Для сборок используются скрипты упаковки из OurDelta.

Во всех сборках (кроме сборки исходного tar-архива) бинарный пакет собирается, а затем пытается устанавливаться. Сборка выполняется на виртуальной машине с установленным компилятором и другими необходимыми инструментами сборки. Виртуальные машины клонируются из эталонной образы перед каждой сборкой (используя параметр --base-image для runvm). Таким образом, исходные образы не изменяются никоим образом, поэтому нет риска «загрязнения» предыдущими сборками, и нет необходимости тщательно очищать после сборки или тестирования.

Сборка исходного tar-архива выполняется на виртуальной машине, которая не сбрасывается после каждой сборки. Это для сохранения настроек общего хранилища bzr внутри виртуальной машины. Таким образом, в каждой сборке достаточно загрузить новые изменения с Launchpad, что экономит значительное количество времени (и пропускную способность Launchpad). Поскольку эта конкретная сборка работает только внутри каталога исходного кода, риск загрязнения межсборкой минимален.

Сборка исходного tar-архива — единственная, которая запускается при совершении коммитов bzr. После успешной сборки исходного tar-архива архив загружается в мастер Buildbot, и все остальные сборщики запускаются для начала сборки. Каждый из них загрузит исходный tar-архив из мастера и выполнит сборку из него, а не из bzr-чек-аута (это правильный способ, так как мы хотим гарантировать, что пользователи, выполняющие сборку из исходного tar-архива, получат те же результаты, что и пакеты, собранные нами).

Поскольку мы используем скрипты OurDelta, которые используют «пекарню» для скриптов сборки, аналогичную исходному tar-архиву, аналогичный tar-архив пекарни генерируется из bzr и загружается в мастер.

Из-за этого запуска невозможно вручную принудительно запустить Buildbot на «последней версии bzr» для сборщиков, не являющихся tar-архивами. Вместо этого для принудительной сборки необходимо установить свойства сборки для исходного tar-архива и пекарни в файлы, которые необходимо протестировать. Но часто проще просто выбрать существующую сборку (с правильным tar-архивом) и использовать функцию «повторная отправка сборки». Другой вариант — принудительно выполнить сборку только для сборки tar-архива; в этом случае она, в свою очередь, запустит все остальные сборки.

Базовое тестирование установки

Для всех сборок (кроме сборки исходного tar-архива) после сборки выполняется тест, где результирующий пакет устанавливается в виртуальной машине и выполняется базовое тестирование.

Тестирование установки выполняется в отдельной виртуальной машине, отличной от той, в которой она была собрана, без инструментов сборки и с очень минимальной установкой (для проверки отсутствия скрытых зависимостей). Тестирование установки в настоящее время очень базовое, в основном просто создание таблицы и вставка строки (было бы неплохо расширить это тестирование до более полного «теста дыма»).

Обратите внимание, что для .deb (Debian и Ubuntu) мы создаем небольшой локальный фейковый репозиторий apt, чтобы правильно проверить, что «apt-get install» может получить любые дополнительные зависимости без каких-либо специальных действий со стороны пользователя.

Тесты обновления для пакетов .deb

Для сборщиков .deb (Debian и Ubuntu) мы выполняем три дополнительных теста обновления.

Два из них устанавливают недавно собранные пакеты MariaDB поверх уже установленного пакета MySQL (по умолчанию для данной версии дистрибутива), а также поверх более ранней версии пакетов MariaDB. Для этого используются отдельные образы виртуальных машин, основанные на образе, используемом в тесте установки, но дополнительно с предварительно установленным MySQL/MariaDB.

Третий тест выполняется на чистом образе без предварительно установленных пакетов MySQL или MariaDB. Тест устанавливает последнюю доступную версию той же основной версии из общедоступного репозитория MariaDB, а затем выполняет dist-upgrade, используя локальный репозиторий в качестве источника новых пакетов. Основная цель этого теста — проверить, что обычные системные обновления, выполняемые через dist-upgrade, работают как ожидается в отношении сервера MariaDB.

Во всех тестах также создается некоторые базовые тестовые данные в процессе установки, чтобы убедиться, что замена старой установки сервера новым пакетом MariaDB не уничтожит существующие данные пользователя! Тест также полезен для проверки корректного выполнения обновления с точки зрения зависимостей и т. п., что довольно сложно реализовать при упаковке .deb.

Тесты обновления для пакетов .rpm

Для сборщиков .rpm (CentOS, Fedora, RHEL, SLES, openSUSE) у нас есть многочисленные тесты обновления, хотя только небольшая часть из них запускается для каждой ветки.

Все тесты обновляют уже существующую установку до новых пакетов MariaDB. Переменными являются: — какой тип существующей установки обновляется: сервер MariaDB, MariaDB Galera, MySQL, сервер Percona или установки mysql/mariadb, предоставленные дистрибутивами; — какая команда используется для обновления: она может выполняться как через upgrade/update (в зависимости от менеджера пакетов), так и install или dist-upgrade; — какие пакеты устанавливаются и обновляются: это может быть минимальный набор, сервер + клиент (плюс любые зависимости, которые они приносят) или полный набор пакетов.

В некоторых случаях тесты также могут устанавливать дополнительные параметры командной строки или переменные среды для менеджера пакетов. Это обычно делается, когда стандартная установка не работает, и менеджер пакетов предлагает использовать другой набор параметров.

Каждый тест использует чистый образ виртуальной машины, устанавливает начальный набор пакетов, а затем использует одну из команд для обновления установки. Он также проверяет, что сервер обновлен, перезапущен и доступен.

Тест mysql-test-run.pl

Для сборщиков .deb (Debian и Ubuntu) мы дополнительно выполняем полный тест mysql-test-run.pl. Это делается с помощью пакета mariadb-test.

Обратите внимание, что в настоящее время из-за ошибки #491349 на более новых версиях Ubuntus стандартный профиль apparmor препятствует запуску mysql-test-run.pl. До тех пор, пока это не будет исправлено, необходимо удалить apparmor перед запуском набора тестов.

См. также

• Настройка Buildbot для виртуальных машин