Вот рецепт настройки узла MariaDB Buildbot для Windows:

1. Подготовьте среду разработки
2. Установите Python, 32-разрядную версию. Twisted не работает на 64-разрядных системах, а buildbot не был должным образом протестирован с Python версии 3.
   Примечание: По состоянию на июнь 2016 года нет свежей версии Twistd для 32-разрядного Python, поэтому необходимо установить 64-разрядную версию. Установлена 64-разрядная версия 2.7.11, кажется, она работает.
3. Установите pywin32. Убедитесь, что версия идеально соответствует вашей версии Python, и загрузите файл .exe, а не zip-архив.
   Примечание: По состоянию на июнь 2016 года использовано pywin32-220.win-amd64-py2.7.exe, кажется, работает.
4. Установите Twisted
   Примечание: По состоянию на июнь 2016 года использовано Twisted 16.2.0 for Python 2.7 64 bits
5. Установите buildbot: Загрузите zip-архив и распакуйте его. В командной строке администратора перейдите в директорию buildbot и выполните команду "python setup.py install". После этого распакованная директория buildbot больше не нужна.
   Примечание: По состоянию на июнь 2016 года использовано buildbot 0.8.12.

После этого выполните следующие команды:

cd <somewhere>
mkdir buildbot
cd buildbot
bzr init-repo .
C:\buildbot\buildbot-slave-0.8.3\build\scripts-2.7\buildslave.bat create-slave --usepty=0 <slavedir> hasky.askmonty.org:9989 <slavename> <passwd>

Измените пути в последней команде в соответствии с местоположением распакованного buildbot.

Значения <slavename> и <passwd> получите у сотрудника MariaDB Corporation или MariaDB Foundation, отвечающего за систему buildbot. <slavedir> можно задать любое значение – <slavename> будет хорошим выбором.

Пожалуйста, отредактируйте файлы <slavedir>\info\admin и <slavedir>\info\host, внеся свои данные. Информация о хосте должна включать вашу версию Windows (32 или 64 бита) и версию Visual Studio.

Вы можете протестировать узел buildbot с помощью этой команды:

C:\buildbot\buildbot-slave-0.8.3\build\scripts-2.7\buildslave.bat start <somewhere>\buildbot\<slavedir>

Когда buildbot запустится, настройте его как службу вместо ручного запуска. Смотрите инструкции здесь. Информация находится в разделе "Настройка службы Windows Buildbot". В этом документе также содержится общая документация по установке Buildbot для Windows.

Почему buildbot должен запускаться как служба

Когда buildbot работает в сеансе пользователя, и приложение, запущенное buildbot, аварийно завершается, вы увидите всплывающее окно с ошибкой. Есть всплывающие окна, генерируемые при постобработке отладки, и есть всплывающие окна, генерируемые системой отчетов об ошибках Windows. Убрать все всплывающие окна сложно (или невозможно для тех, кто не пробовал это раньше). Поэтому запускайте buildbot как службу. В службах нет всплывающих окон.

Общие ошибки Buildbot для Windows

Тест зависает после попытки вызвать cdb для вывода трассировки стека.

MTR пытается вызвать cdb с помощью Perl-оператора обратных кавычек, когда mysqld.exe завершается аварийно. При первом запуске cdb загружает общедоступные символы Windows с msdl.microsoft.com/download/symbols. Символы кэшируются в C:\cdb_symbols, и последующие запуски будут быстрее, однако анализ дампов памяти при первой ошибке обычно занимает некоторое время.

Если это вас беспокоит, запустите тест с помощью --mysqld=--gdb , что приведет к тому, что не будут созданы файлы дампов памяти и, таким образом, не будет вызываться cdb.

Ошибка Buildbot The process cannot access the file because it is being used by another process

Это происходит из-за того, что buildbot не удаляет оставшиеся процессы от предыдущего запуска, и эти процессы могут удерживать блокировки файлов, необходимые для запуска нового сборки. Текущее решение — использовать объекты задач Windows, позволяющие завершать целые деревья процессов. Мы используем специальную утилиту "запуска процессов" под названием "dojob". Это также потребует изменения конфигурации buildbot для сборщика.

Загрузите dojob.cpp и скомпилируйте его с помощью

  cl dojob.cpp

Затем поместите dojob.exe в директорию, включенную в переменную среды PATH переменная окружения. Затем измените конфигурацию buildbot для использования "dojob" для каждой команды, как замену для "cmd /c", например

factory.addStep(Compile(
        name = "cmake",
        command=["dojob", WithProperties("cd c:\\buildbot\\%(buildername)s\\build && cmake .")]
));

Ошибка Buildbot ShellCommand.failed: command failed: SIGKILL failed to kill process

(Встречается очень редко?). Обычно это происходит после многократной повторной попытки неудачных тестов. Похоже, что опция --retries= MTR небезопасна для использования в Windows. Решение — запустить тест без --retries.

Ошибка Buildbot Connection to the other side was lost in a non-clean fashion.

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

• В файле buildbot.tac задайте более высокое значение keepalive, например, 60000.
  Примечание: Для текущих версий (по состоянию на июнь 2016 года) противоположное решение сработало: keepalive = 60. Значение KeepAliveTime в реестре Windows было установлено на 60000, как предложено ниже, но нет доказательств того, что это повлияло на ситуацию.
  
• Если хост Windows работает внутри VMWare, замените сетевой адаптер e1000 на vmxnet3
• Если ваш хост сборки находится за брандмауэром, убедитесь, что брандмауэр не отключает неактивные соединения слишком быстро. Установите таймаут по крайней мере на 24 часа.
• Если ваш хост сборки находится за брандмауэром, рассмотрите возможность отключения встроенного брандмауэра Windows, чтобы избежать потенциальной точки отказа.
• Измените значение параметра реестра Windows KeepAliveTime на меньшее значение, например, 60000 (равно 60 секундам). Дополнительные сведения см. на TechNet
• Убедитесь, что у мастера buildbot нет длительных периодов высокой загрузки процессора (100%), так как это может препятствовать работе keepalive. Если мастер buildbot twisted.log сообщает о частой загрузке данных из кэшированных pickle-файлов, увеличьте значение buildCacheSize в файле конфигурации мастера, чтобы оно было больше, чем количество сборок на сборщик, указанное в файле журнала.

Альтернативная настройка Buildbot для Windows (экспериментальная)

В случае, если стандартная настройка Buildbot для Windows недостаточно надежна из-за ошибок «потеряно соединение с другой стороной некорректно», можно использовать следующую альтернативную настройку. Она запускает демона buildbot на хосте Linux, выполняя сборки на Windows, таким образом, обходя проблемы Twisted в Windows.

Обратите внимание, что описанная ниже процедура _существенно_ снижает общую безопасность вашего хоста Windows. Сильно рекомендуется использовать правильно защищенную виртуальную машину.

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

• Установите FreeSSHd на Windows. Комбинация OpenSSHd/Cygwin вряд ли сработает.
  • Не запускайте FreeSSHd как службу, а как консольное приложение при старте пользователя, под которым выполняются сборки. Это позволяет правильно работать с интерфейсом FreeSSHd;
  • Сгенерируйте пару открытых и закрытых ключей с помощью PuTTYGen и поместите открытый ключ в соответствующий файл в директории ключей, указанной в графическом интерфейсе FreeSSHd
  • Используя графический интерфейс FreeSSHd, создайте нового пользователя и настройте его на аутентификацию по ключу;
  • Укажите путь к домашней директории SFTP в каталог, в котором будут проводиться сборки.

• Отключите UAC (Управление доступом пользователей) (или установите его на минимальный уровень) с помощью панели управления "Пользователи". Добавьте пользователя buildbot в группу администраторов.

• Экспортируйте закрытый ключ из PuTTYGen и скопируйте его на хост Linux.

• Установите buildbot на хосте Linux

• Файл конфигурации buildbot будет выглядеть примерно так:

f_win2008r2_i386_release.addStep(ShellCommand(
        command=["ssh", "-i", "/home/buildbot/keys/id_rsa", "buildbot@win2008r2-build", "cmd", "/C", "whoami"]
));

Следующие соображения по buildbot применимы к этой настройке:

• buildbot не будет правильно очищать каталог сборки на хосте Windows перед каждой сборкой (он будет очищать только на стороне Linux). Поэтому необходимо включить очистку каталога с помощью rmdir в качестве явного первого шага в процессе сборки;
• Bzr() нельзя использовать для проверки состояния деревьев BZR, так как он предполагает, что команда bzr checkout будет запущена локально. Вместо этого необходимо явно использовать команду bzr checkout через SSH-команду;