Buildbot ToDo

Задачи высокой приоритетности, с высокой отдачей

• Добавить возможность на веб-страницах помечать определенные сборки высокой приоритетностью, чтобы они обрабатывались раньше других, по мере освобождения серверов сборки. Необходимо иметь возможность помечать ожидающие сборки не только индивидуально, но и по ветке, а также по (ветка,ревизия). Функция должна взаимодействовать осмысленным образом с существующей возможностью "nextBuild" для приоритизации сборок (http://buildbot.net/buildbot/docs/0.8.4/full.html#Prioritizing-Builds). Например, она могла бы устанавливать соответствующие свойства где-то, доступные для функции nextBuild.
• Необходимо иметь возможность остановить все выполняемые сборки и удалить все ожидающие сборки для заданной комбинации ветки и ревизии. Возможность вручную отменить ожидающую или выполняющуюся сборку, но это становится крайне неудобно, когда есть много билдеров.
  • Комментарии из рассылки buildbot: «Уже есть кнопка (скрытая на странице изменений) для остановки всех сборок, связанных с изменением. К сожалению, единственный способ попасть на эту страницу — через водопад». «Обратите внимание, что кнопка на странице изменений отменяет только еще ожидающие сборки, она не останавливает уже запущенные сборки».
• Исправить проблему при одновременной отправке нескольких ревизий bzr:
  • Buildbot должен подождать несколько мгновений перед запуском сборки, а затем начать сборку последней (в настоящее время он, похоже, собирает первую ревизию немедленно и даже часто, похоже, не собирает последнюю ревизию вообще, путаясь в порядке)
  • При отправке изменений, изменяющих номера ревизий, отображение сетки может сильно нарушиться, было бы неплохо как-то это исправить.
• Любая ошибка, кроме ошибки компиляции/тестирования, должна означать повторную сборку. Ошибки, такие как перезагрузка или потеря подключения сервера сборки или истечение времени ожидания операции bazaar, должны интерпретироваться так, как будто сборка никогда не происходила, и система должна повторить попытку сборки.
• В шаге bzr source повторить попытку проверки кода несколько раз, если она завершилась ошибкой (чтобы повысить устойчивость к временным проблемам Launchpad, которые мы видим часто). Возможно, это можно сделать как общую опциональную функцию Buildbot для всех поддерживаемых систем управления версиями, или, возможно, специфичную для bzr в зависимости от того, что может работать.
• Исправить набор тестов PBXT в --valgrind; после этого включить его в список основных наборов тестов, чтобы он тестировался на всех платформах (и удалить специальные дополнительные шаги тестирования pbxt в некоторых сборках Buildbot, так как они больше не понадобятся).
• Загрузка статистики. Нам нужно, чтобы можно было увидеть, не приведет ли добавление ещё одного дерева к голоду buildbot:
  • Процент загруженности доступных серверов сборки
  • Медиана/максимальное время отклика (Сколько времени мне нужно ждать после отправки, чтобы тест был завершён)
• Исправить то, что mysql-test-run использует --skip-ssl по умолчанию.
• Исправить то, что mysql-test-run.pl --mem не очищает должным образом /dev/shm/var* (чтобы мы могли использовать --mem и --parallel опцию для ускорения работы более мощных машин).
• Для триггерных сборок (т.е. один билдер создает архив исходного кода, который использует другой билдер) сделать так, чтобы отправленные изменения также передавались, чтобы список виновных на странице сборки работал (в настоящее время список виновных пуст).
• Обновить Buildbot до версии 0.8 на главном сервере. Затем использовать возможность использования сервера MariaDB в качестве бэкенда для ускорения (надеюсь) и более гибкого запроса истории buildbot.

Задачи низкой приоритетности

• Установка должна быть проще для нового пользователя. В идеале должен быть один архив, который можно скачать, распаковать и запустить. Внутри архива должен быть скрипт и/или конфигурационные файлы, которые позволяют добавить сервер сборки в автоматический запуск. Следующего быть не должно:
  • Зависимость сервера сборки от множества библиотек python. Доставить их.
  • То же самое для bzr
  • То же самое для mysqld. Скачать/скомпилировать/установить все необходимое в директорию buildbot.

Если этого не сделать, мы никогда не получим большого участия со стороны старых или необычных машин. Владельцы таких машин не имеют последних библиотек, установка которых требует некоторой ручной работы, что просто устанавливает слишком высокий порог.

• Проверить наблюдения/ошибки архивиста, что информация `uname` сервера сборки исчезает при отключении сервера.
• Автообновление с интервалом времени (возможно, через ajax, чтобы сократить передачу), чтобы пользователи могли знать, когда запускать сервер сборки.
• На странице «водопад» вторая строка сверху — «текущая активность». При отображении определенной ветки («?branch=5.1»), «текущая активность» для узлов, которые в данный момент собирают другую ветку, может также отображать имя ветки (как ссылку на страницу «водопад» для этой ветки), чтобы избежать путаницы, что она активна в текущей ветке.
• Запустить с --valgrind-mysqld вместо --valgrind. Нет смысла проверять mysqltest с помощью Valgrind, так как в любом случае мы игнорируем любые ошибки в этой программе.
• Показывать ожидающие сборки для сервера на странице «билдеры», например, http://askmonty.org/buildbot/builders/hardy-x86-rtai
• Отображать даты в местном времени клиента. Один из способов — использовать JavaScript: http://articles.techrepublic.com.com/5100-10878_11-6016329.html (было бы неплохо, если бы некоторые даты отображались даже при отсутствии JavaScript).
• Проверить, достаточно ли исправлена InnoDB, чтобы не было утечек памяти Valgrind с innodb_use_sys_malloc; если это так, удалите обходной путь в mysql-test-run.pl для отключения этого в случае Valgrind.
• Исправить проблему, когда некорректный регулярное выражение вызывает ошибку сборки (пример: https://buildbot.askmonty.org/buildbot/builders/sol-sparc-32/builds/157/steps/compile/logs/err.text). Проблема в том, что Buildbot извлекает регулярные выражения из файла подавления в дереве MariaDB и пытается скомпилировать их; если это вызывает ошибку, то ошибку нужно перехватить (и, возможно, предупредить об этом), а не выводить из строя всю сборку.

Улучшение сборки и тестирования бинарных пакетов

• Добавить проверку `apt-get source mariadb-server` в Buildbot (для тестирования пакетов).
• Добавить тестирование пакета bintar с реальным запуском сервера mysqld_safe, а также тестирование на различных дистрибутивах/версиях, отличных от тех, которые были построены (например, hardy<->jaunty).
• При построении пакета подписать .deb с тестовым ключом, чтобы более точно проверить реальный процесс сборки.
• Переключиться на сборку пакетов bintar на centos 5, чтобы работать с более старыми версиями glibc? Или, возможно, даже Debian 4, который, по-моему, ещё старше? Но выполнить тест установки в Buildbot также на других/более новых дистрибутивах (вероятно, стоит протестировать на нескольких в каждой сборке).
• Добавить шаг проверки для .deb, который проверяет обновление с более ранней версии MariaDB (в настоящее время мы проверяем только обновление с MySQL).
• Добавить функцию «следить за логом» в runvm (которая выполняет `ssh guest tail -f log > log`). Используйте это в шаге Buildbot по упаковке, который выполняет mysql-test-run.pl, чтобы получить журналы сервера mysqld.X.err.Y, как и для сборок без kvm.
• Для runvm: добавьте опции "-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" к команде ssh, используемой для входа в гостевую машину виртуальной среды, чтобы не получать ошибку входа из-за различных ключей хоста на разных гостевых машинах виртуальной среды.

Деревья разработки

Идея заключается в том, чтобы настроить каждый разработчик/группа имели дерево разработки. Любая отправка в это дерево в первую очередь пройдет полный цикл тестирования в Buildbot. Если все результаты будут положительными, оно автоматически будет отправлено в основное дерево. Если другая отправка поступит первой, она автоматически сольфует новые данные и повторит полный тест Buildbot. Если возникнет проблема (ошибка тестирования или конфликт слияния), будет отправлено письмо с подробностями.

• Сначала получить что-то работающее, простое.
• Дерево разработки на человека/капитана
• mysqltest --require не-разработка для ускорения Valgrind