TOC

Как настроить непрерывную интеграцию с Buildbot в Ubuntu 16.04

Вступление

Buildbot - основанная на Python система непрерывной интеграции для автоматизации процессов сборки, тестирования и выпуска программного обеспечения. В предыдущих уроках мы https://www.digitalocean.com/community/tutorials/how-to-install-buildbot-on-ubuntu-16-04 уже установили Buildbot], https://www.digitalocean.com/ community / tutorials / how-to-create-systemd-unit-files-for-buildbot [созданные файлы модулей systemd], чтобы позволить системе инициализации сервера управлять процессами, и https://www.digitalocean.com/community/tutorials / how-to-configure-buildbot-with-ssl-using-an-nginx-reverse-proxy [настроил Nginx в качестве обратного прокси-сервера] для направления запросов браузера, защищенных SSL, в веб-интерфейс Buildbot.

В этом руководстве мы покажем, как настроить систему непрерывной интеграции для автоматического тестирования новых изменений в хранилище. Мы будем использовать простое приложение Node.js для демонстрации процесса тестирования и необходимой конфигурации. Чтобы изолировать нашу среду тестирования от хоста Buildbot, мы создадим образ Docker, который будет работать как наш работник Buildbot. Затем мы настроим мастер Buildbot для отслеживания изменений в репозитории GitHub, автоматически проверяя каждый раз, когда обнаруживаются новые изменения.

Предпосылки

Чтобы следовать этому уроку, вам понадобится:

  • * Один сервер Ubuntu 16.04 с не менее 1 ГБ ОЗУ *, настроенный для пользователя без полномочий root + sudo + и брандмауэра, следуя https://www.digitalocean.com/community/tutorials/initial-server-setup -with-ubuntu-16-04 [Руководство по первоначальной настройке сервера Ubuntu 16.04]

Кроме того, вам необходимо пройти следующие уроки на сервере:

Когда вы выполните эти требования, вы готовы начать.

Создайте репозиторий примеров в GitHub

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

В своем веб-браузере перейдите на hello hapi приложение на GitHub, которое мы будем использовать для демонстрации. Это приложение представляет собой простую программу «hello world» с несколькими модульными и интеграционными тестами, написанную на hapi, веб-инфраструктуре Node.js.

Поскольку этот пример используется для демонстрации множества систем непрерывной интеграции, вы можете заметить некоторые файлы, используемые для определения конвейеров для других систем. Для Buildbot мы будем определять этапы сборки на сервере, а не в репозитории.

Позже мы будем настраивать webhooks для Buildbot в нашем репозитории, чтобы изменения автоматически запускали новые тесты. На данный момент нам нужно создать наш собственный форк репозитория.

Нажмите кнопку * Fork * в правом верхнем углу экрана:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/fork_repository.png [кнопка репозитория вилок GitHub]

Если вы являетесь членом организации GitHub, вас могут спросить, куда вы хотите подключить репозиторий:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/where_to_fork.png [GitHub, где можно форк репо]

После выбора учетной записи или организации копия репозитория будет добавлена ​​в вашу учетную запись:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/your_fork.png [GitHub your fork]

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

Настроить Docker для Buildbot

Мы начнем с настройки Docker, чтобы Buildbot использовал его для сборки. Для начала нам нужно настроить доступ между Docker и Buildbot. После этого нам нужно создать образ Docker для использования в наших контейнерах.

Настроить доступ к Docker для Buildbot

Нам нужно разрешить Buildbot и Docker общаться на нескольких разных уровнях.

Во-первых, нам нужно убедиться, что процесс Buildbot имеет доступ к демону Docker. Мы можем сделать это, добавив пользователя * buildbot * в группу * docker *:

sudo usermod -aG docker buildbot

Эта новая группа будет доступна Buildbot при следующем перезапуске мастера Buildbot, что мы и сделаем позже.

Мы также должны убедиться, что Buildbot знает, как общаться с Docker. Поскольку Buildbot написан на Python, он использует https://docker-py.readthedocs.io/en/stable/ [+ docker-py + Python package] вместо прямой выдачи команд Docker.

Вы можете установить + docker-py +, набрав:

sudo -H pip install docker-py

Наконец, нам нужно открыть сетевой доступ из контейнеров к хост-системе и внешнему миру. Мы можем сделать это, разрешив исключение для интерфейса + docker0 + в нашем брандмауэре.

Разрешите доступ к трафику из интерфейса + docker0 +, набрав:

sudo ufw allow in on docker0

Buildbot и Docker теперь должны иметь возможность эффективно общаться друг с другом.

Создание образа Docker для использования в качестве рабочего Buildbot

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

К счастью, проект Buildbot предоставляет базовый Buildbot рабочий образ, в котором уже настроены все специфичные для Buildbot требования. Нам просто нужно использовать этот образ в качестве основы и установить дополнительные зависимости, которые требуются нашему проекту.

В нашем случае приложение example, которое мы будем использовать, является приложением Node.js, поэтому нам необходимо убедиться, что Node.js доступен на изображении.

Чтобы определить наш образ, создайте и откройте файл с именем + Dockerfile + в вашем домашнем каталоге:

nano ~/Dockerfile

В этом файле мы основываем наш образ на рабочем образе Buildbot, используя + FROM buildbot / buildbot-worker: master +. После этого мы можем переключиться на пользователя + root, чтобы установить Node.js, а затем переключиться обратно на пользователя` + buildbot`, чтобы выполнить действительные команды:

~ / Dockerfile

FROM buildbot/buildbot-worker:master

USER root
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt-get install -y nodejs
USER buildbot

Сохраните и закройте файл, когда вы закончите.

Как только у нас есть + Dockerfile, мы можем построить наш образ из него. Мы будем вызывать образ + npm-worker + для явного определения дополнительных зависимостей, которые мы установили:

docker build -t npm-worker - < ~/Dockerfile

Docker начнет создавать ваш образ на основе команд, которые мы описали в + Dockerfile +. Он запустит базовый образ и его слои зависимостей, установит Node.js, а затем сохранит полученную среду в образ с именем + npm-worker +.

Настройте мастер Buildbot

Теперь, когда у нас есть образ Docker, мы можем настроить мастер Buildbot для его использования.

Поскольку мы определяем совершенно новый процесс сборки и поскольку наши настройки для основной конфигурации до этого момента были минимальными, мы начнем нашу настройку с нуля. Чтобы не потерять текущую информацию, мы переместим исходный файл в файл резервной копии:

sudo mv /home/buildbot/master/master.cfg /home/buildbot/master/master.cfg.bak

Отобразите конфигурацию файла резервной копии, чтобы мы могли скопировать несколько важных значений для использования в нашей новой конфигурации:

sudo cat /home/buildbot/master/master.cfg.bak

Важными частями, которые мы хотим перенести в новую конфигурацию, являются учетные данные и разрешения пользователя. Ищите разделы конфигурации, начинающиеся с + c ['www'] ['authz'] + и + c ['www'] ['auth'] + в выходных данных:

Output. . .
c['www']['authz'] = util.Authz(
       allowRules = [
               util.AnyEndpointMatcher(role="admins")
       ],
       roleMatchers = [
               util.RolesFromUsername(roles=['admins'], usernames=[''])
       ]
)
c['www']['auth'] = util.UserPasswordAuth({'': ''})
. . .

Скопируйте и сохраните эти строки где-нибудь, чтобы вы могли ссылаться на них позже. Мы добавим эти данные в нашу новую основную конфигурацию Buildbot, чтобы сохранить настройки пользователя и аутентификации.

Теперь создайте новый файл + master.cfg +, в котором мы можем переопределить поведение нашего экземпляра Buildbot:

sudo nano /home/buildbot/master/master.cfg

Мы определим нашу новую главную конфигурацию Buildbot в этом файле.

Настройка базовой конфигурации проекта

Файл конфигурации Buildbot на самом деле представляет собой модуль Python, который обеспечивает большую гибкость за счет некоторой сложности.

Мы начнем с некоторой базовой конфигурации. Вставьте следующие строки в ваш файл:

/home/buildbot/master/master.cfg

# -*- python -*-
# ex: set filetype=python:
from buildbot.plugins import *


c = BuildmasterConfig = {}

# Basic config
c['buildbotNetUsageData'] = None
c['title'] = "Hello Hapi"
c['titleURL'] = "https://github.com//hello_hapi"
c['buildbotURL'] = "https:///"
c['protocols'] = {'pb': {'port': 9989}}

Верхняя часть файла содержит несколько комментариев, которые многие текстовые редакторы могут интерпретировать, чтобы правильно применять подсветку синтаксиса. После этого мы импортируем все из пакета + buildbot.plugins +, чтобы у нас были инструменты, доступные для построения нашей конфигурации.

Конфигурация Buildbot полностью определяется словарем с именем + BuildmasterConfig +, поэтому для запуска этой переменной мы устанавливаем пустой словарь. Мы создаем сокращенную переменную с именем + c +, установленную в этот же словарь, чтобы уменьшить объем ввода, необходимый для всего файла.

Некоторые вещи, которые нужно отметить в конфигурации, следующие:

  • + buildbot GetImageData имеет значение` + None`. Измените это на строку " basic ", если вы хотите сообщить разработчикам об использовании данных.

  • + Title + и + titleURL + отражают имя проекта и репозиторий GitHub. Используйте ссылку на свой собственный форк.

  • + buildbotURL + устанавливается для имени домена, защищенного с помощью мастера сборки Buildbot. Не забудьте начать с + https: // + и завершить косой чертой + / +.

  • В отличие от нашей последней конфигурации, определение + protocol не привязывается к localhost. Нам нужно разрешить соединения из контейнеров Docker через сеть моста Docker + docker0 +.

Настройте Docker Worker

Далее нам нужно определить нашего работника Docker. Buildbot будет использовать Docker для предоставления работникам по мере необходимости. Для этого ему нужно знать, как подключиться к Docker и какой образ использовать.

Вставьте следующее внизу файла:

/home/buildbot/master/master.cfg

. . .

# Workers
c['workers'] = []
c['workers'].append(worker.DockerLatentWorker("npm-docker-worker", None,
                       docker_host='unix://var/run/docker.sock',
                       image='npm-worker',
                       masterFQDN=''))

Строка + c ['worker'] = [] + демонстрирует основное соглашение, которое мы будем использовать при прохождении конфигурации. Мы устанавливаем ключ в словаре конфигурации в пустой список. Затем мы добавляем элементы в список для реализации фактической конфигурации. Это дает нам возможность добавлять дополнительные элементы позже.

Чтобы определить нашего работника, мы создаем и добавляем экземпляр + worker.DockerLatentWorker + в список + worker +. Мы называем этот работник + npm-docker-worker +, чтобы мы могли обратиться к нему позже в конфигурации. Затем мы устанавливаем + docker_host + в расположение сокета Docker и предоставляем имя созданного нами образа Docker (+ npm-worker + в нашем случае). Мы устанавливаем + masterFQDN + для имени домена нашего мастера Buildbot, чтобы убедиться, что контейнер может достичь мастера независимо от внутренних настроек имени хоста сервера.

Настройте Планировщик

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

Вставьте следующую конфигурацию внизу файла:

/home/buildbot/master/master.cfg

. . .

# Schedulers
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
               name="hello_hapi",
               change_filter=util.ChangeFilter(project='/hello_hapi', branch='master'),
               treeStableTimer=3,
               builderNames=["npm"]))

Мы используем тот же метод добавления нашей конфигурации в пустой список здесь. В этом случае мы добавляем экземпляр + schedulers.SingleBranchScheduler +. Это позволяет нам наблюдать за одной веткой в ​​хранилище, что упрощает настройку.

Мы называем планировщик «hello_hapi», чтобы правильно его идентифицировать. Затем мы определяем фильтр изменений. Планировщику может быть передано много разных наборов изменений из разных источников. Фильтры изменений определяют набор критериев, которые определяют, должно ли рассматриваемое изменение обрабатываться этим конкретным планировщиком. В нашем случае мы фильтруем по названию проекта, о котором сообщит веб-крючок GitHub, и по ветке, которую мы хотим наблюдать.

Затем мы устанавливаем + treeStableTimer +, который определяет время ожидания дополнительных изменений, равным 3 секундам. Это помогает предотвратить построение Buildbot множества небольших сборок для изменений, которые тесно связаны между собой. Наконец, мы определяем имена строителей, которые должны использоваться, когда изменение соответствует нашим критериям (мы определим этого строителя на мгновение).

Настройка фабрики сборки для проектов Node.js

Далее мы настроим фабрику сборки для обработки проектов Node.js. Фабрика сборки отвечает за определение шагов, которые необходимо предпринять для сборки или, в нашем случае, проекта. Это делается путем определения экземпляра + util.BuildFactory + и последующего добавления последовательных шагов, которые должны быть выполнены.

Вставьте следующее внизу вашего файла:

/home/buildbot/master/master.cfg

. . .

# Build Factories
npm_f = util.BuildFactory()
npm_f.addStep(steps.GitHub(repourl='git://github.com//hello_hapi.git', mode='full', method='clobber'))
npm_f.addStep(steps.ShellCommand(command=["npm", "install"]))
npm_f.addStep(steps.ShellCommand(command=["npm", "test"]))

Сначала мы определяем фабрику сборки с именем + npm_f +. Первый шаг, который мы добавим, это экземпляр + steps.GitHub. Здесь мы устанавливаем хранилище, которое должно быть снесено в конструктор. Мы устанавливаем для + mode значение« full », а для« + method »-« clobber », чтобы полностью очистить наш репозиторий каждый раз, когда мы извлекаем новый код.

Вторым и третьим шагами, которые мы добавляем, являются объекты + steps.ShellCommand +, которые определяют команды оболочки для запуска внутри репозитория во время сборки. В нашем случае нам нужно запустить + npm install +, чтобы собрать зависимости проекта. После этого нам нужно запустить + npm test для запуска вашего набора тестов. Определение команд в виде списка (+ [" npm "," install "] +) рекомендуется в большинстве случаев, чтобы не допустить применения оболочкой нежелательного расширения для элементов внутри команды.

Настройте Строителя

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

Вставьте следующую конфигурацию внизу файла:

/home/buildbot/master/master.cfg

. . .

# Builders
c['builders'] = []
c['builders'].append(
       util.BuilderConfig(name="npm",
               workernames=["npm-docker-worker"],
               factory=npm_f))

Мы добавляем объект + util.BuilderConfig + в список + builders +. Помните, что наша фабрика сборки называется + npm_f +, что наш рабочий Docker называется + npm-docker-worker +, и что планировщик, который мы определили, будет передавать задачи работнику с именем + npm +. Наш конструктор определяет взаимосвязь между этими элементами, так что изменения в нашем планировщике приведут к выполнению шагов фабрики сборки в Docker.

Настройте базу данных и веб-интерфейс

Наконец, мы можем настроить параметры базы данных и веб-интерфейса. В отличие от многих предыдущих пунктов, эти две настройки определены как словари, а не списки. Словарь + db + просто указывает на файл + state.sqlite +, который уже находится в нашем каталоге + / home / buildbot / master +. Словарь + www + содержит значительное количество дополнительных настроек.

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

/home/buildbot/master/master.cfg

. . .

# Database
c['db'] = { 'db_url': "sqlite:///state.sqlite",}

# Web Interface
c['www'] = dict(port=8010, plugins=dict(waterfall_view={}, console_view={}))













# GitHub webhook receiver
c['www']['change_hook_dialects'] = {
       'github': {
               'secret': '',
               'strict': True,
       }
}

После определения настроек базы данных мы создаем словарь + www +, который начинается с определения порта для прослушивания и некоторых представлений, включаемых в веб-интерфейс. Далее мы добавляем требования аутентификации, которые мы извлекли из предыдущего файла конфигурации Buildbot.

В конце мы определим словарь + change_hook_dialects + в словаре + www +. Мы используем это для определения ловушки изменений GitHub, которая будет прослушивать сообщения webhook от GitHub. Выберите безопасную ключевую фразу для своего + secret +, которая будет использоваться GitHub для аутентификации отправляемых им сообщений.

Когда вы закончите, сохраните и закройте файл.

Перезапустите мастер Buildbot, чтобы применить новую конфигурацию

На этом этапе мы полностью перенастроили основной процесс Buildbot. Нам нужно перезапустить мастер-процесс Buildbot, чтобы изменения вступили в силу.

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

Проверьте синтаксис файла, набрав:

sudo buildbot checkconfig /home/buildbot/master

Команда сообщит о любых найденных проблемах. Если ошибок не обнаружено, вы получите сообщение, которое выглядит так:

OutputConfig file is good!

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

Если ошибок больше нет, перезапустите главную службу Buildbot, набрав:

sudo systemctl restart buildbot-master

Проверьте, была ли операция успешной, набрав:

sudo systemctl status buildbot-master
Output● buildbot-master.service - BuildBot master service
  Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled)
   since Tue 2017-06-27 19:24:07 UTC; 2s ago
Main PID: 8298 (buildbot)
   Tasks: 2
  Memory: 51.7M
     CPU: 1.782s
  CGroup: /system.slice/buildbot-master.service
          └─8298 /usr/bin/python /usr/local/bin/buildbot start --nodaemon

Jun 27 19:24:07 bb5 systemd[1]: Started BuildBot master service

Если служба смогла успешно перезапуститься, она будет помечена как активная.

Создайте GitHub Webhook в репозитории примеров

Теперь, когда Buildbot настроен с веб-конечной точкой для приема сообщений GitHub, мы можем настроить веб-крюк для нашего форка.

В вашем веб-браузере перейдите на ваш форк репозитория примера проекта:

https://github.com//hello_hapi

Нажмите на вкладку * Настройки *, чтобы просмотреть настройки проекта. В левом меню на странице настроек нажмите * Webhooks * (GitHub может попросить вас повторно ввести пароль во время этого процесса для подтверждения вашей личности):

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_initial_page.png [начальная страница веб-хитов GitHub]

Нажмите кнопку * Добавить веб-крючок * справа, чтобы добавить новый веб-крючок.

На следующей странице будет форма для определения вашего webhook. В поле * Payload URL * добавьте URL-адрес для конечной точки перехвата изменений GitHub вашего проекта. Это делается путем указания протокола + https: // +, за которым следует доменное имя вашего мастера Buildbot, а затем + / change_hook / github +.

Оставьте тип содержимого установленным на + application / x-www-form-urlencoded +. В поле * Secret * введите секретную фразу-пароль, которую вы выбрали в главном файле конфигурации Buildbot. Вы можете оставить выбранным триггер «Просто push-событие» и установить флажок «Активно»:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_form.png [форма веб-поиска GitHub]

Когда вы закончите, нажмите кнопку * Добавить веб-крючок *.

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

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/webhooks_success_icon.png [значок успеха веб-крючка GitHub]

Если вместо этого вы видите красный крестик, снова нажмите на веб-крючок, а затем прокрутите вниз до раздела * Недавние поставки *. Больше информации о том, что пошло не так, доступно, если вы нажмете на неудачную доставку.

Тестирование Webhook

Теперь, когда у нас есть наш webhook, мы можем проверить, чтобы убедиться, что когда мы вносим изменения в наш репозиторий, Buildbot получает предупреждение, запускает сборку в Docker и может успешно выполнить набор тестов.

На главной странице вашего форка GitHub нажмите кнопку * Создать новый файл * слева от зеленой кнопки «Клонировать или скачать»:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/create_new_file_button.png [кнопка создания нового файла в GitHub]

На следующем экране создайте + dummy_file + и заполните текст:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/create_dummy_file.png [GitHub создать фиктивный файл]

Нажмите кнопку * Подтвердить новый файл * внизу страницы, когда вы закончите.

Затем перейдите в веб-интерфейс Buildbot и войдите в систему, если вы еще не прошли аутентификацию.

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

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/in_progress_build.png [Buildbot в процессе сборки]

Если сборка уже завершена, она будет находиться в разделе «последние сборки»:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_complete.png [сборка Buildbot завершена]

Имя сборщика, которое мы определили, «npm», используется для обозначения сборки. В этом примере мы также можем увидеть более старый прогон примера компоновщика из предыдущей конфигурации Master.

Независимо от прогресса, нажмите на имя сборщика и ссылку на номер сборки, чтобы перейти на страницу сведений о сборке. Это представление содержит информацию о построении, которое было проведено. Каждый шаг, который мы добавили к фабрике сборки, будет отображаться в отдельном разделе:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_details_view.png [представление сведений о сборке Buildbot]

Если вы нажмете на шаг, вывод команды будет отображен. Это может помочь с отладкой, если что-то пойдет не так:

изображение: https: //assets.digitalocean.com/articles/buildbot_usage_1604/build_step_output.png [вывод шага сборки Buildbot]

В приведенном выше выводе мы можем убедиться, что Buildbot успешно выполнил три теста в нашем наборе тестов.

Если сборка не завершилась успешно, другие области, которые вы можете проверить, - это другие вкладки на странице сведений о сборке, а также файл + / home / buildbot / master / twistd.log +.

Настройка сервисов Buildbot

Прежде чем мы закончим, мы должны внести некоторые коррективы в наши сервисы Buildbot.

В настоящее время у нас есть служба + buildbot-worker +, определенная для работника, которого мы больше не используем (наш работник Docker запускается автоматически при необходимости). Мы должны остановить и отключить нашего старого работника.

Чтобы остановить работающую службу и отключить ее запуск при загрузке, введите:

sudo systemctl stop buildbot-worker
sudo systemctl disable buildbot-worker
OutputRemoved symlink /etc/systemd/system/buildbot-master.service.wants/buildbot-worker.service.

Приведенный выше вывод указывает, что рабочий не будет запущен при следующей загрузке. Чтобы убедиться, что служба больше не работает, введите:

sudo systemctl status buildbot-worker
Output● buildbot-worker.service - BuildBot worker service
  Loaded: loaded (/etc/systemd/system/buildbot-worker.service; disabled; vendor preset: enabled)


Jun 27 21:12:48 bb6 systemd[1]: Started BuildBot worker service.
Jun 27 21:55:51 bb6 systemd[1]: Stopping BuildBot worker service...
Jun 27 21:55:51 bb6 systemd[1]: Stopped BuildBot worker service.

Последнее, что мы должны сделать, это установить мягкую зависимость между нашей главной службой Buildbot и демоном Docker. Поскольку главная служба Buildbot не сможет подготовить новых работников без Docker, мы должны определить это требование.

Откройте файл + buildbot-master.service ie в каталоге` + / etc / systemd / system`, чтобы настроить файл сервиса:

sudo nano /etc/systemd/system/buildbot-master.service

В разделе + [Unit] + добавьте + docker.service к директиве` + After` после элемента + network.target. Добавьте дополнительную директиву + Wants +, которая также называет + docker.service +. + Wants + устанавливает мягкую зависимость, в то время как директива + After + устанавливает начальный порядок:

/etc/systemd/system/buildbot-master.service

[Unit]
Description=BuildBot master service
After=network.target


[Service]
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/master
ExecStart=/usr/local/bin/buildbot start --nodaemon

[Install]
WantedBy=multi-user.target

Сохраните и закройте файл, когда вы закончите.

Перезагрузите демон systemd и службу для немедленного применения конфигурации:

sudo systemctl daemon-reload
sudo systemctl restart buildbot-master

Основной процесс Buildbot теперь должен быть запущен после того, как Docker станет доступен.

Заключение

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

Related