(Зображення від
Привіт!
Мене звати Євген Черкін, я програміст команди розробників у гірничодобувній компанії Поліметалу.
Приступаючи до будь-якого великого проекту починаєш замислюватися: «Який софт краще використовувати для його обслуговування?». IT-проект перед випуском чергової версії проходить низку етапів. Добре, коли ланцюжок цих етапів автоматизований. Сам собою автоматизований процес випуску нової версії IT-проекту називається Безперервна інтеграція. BuildBot для нас виявився добрим помічником, який реалізує цей процес.
У цій статті я вирішив подати огляд можливостей BuildBot. На що здатний цей софт? Як до нього підступитися і як побудувати з ним нормальні ЕФЕКТИВНІ РОБОЧІ ВІДНОСИНИ? Наш досвід ви можете застосувати і у себе, створивши на своїй машині робочий сервіс складання та тестування вашого проекту.
Зміст
Зміст
1. Чому BuildBot?
Раніше на habr-e я зустрічав статті про реалізацію Безперервна інтеграція з використанням BuildBot. Наприклад, здалася мені найбільш інформативною. Є інший приклад - . Ці статті можна приправити , а навздогін, англійською мовою. У купе виходить непогана відправна точка. Прочитавши ці статті, ви напевно відразу захочете щось на BuildBot зробити.
Стоп! А хтось взагалі використав його у своїх проектах? Виявляється так, застосували його у своїх завданнях. Можна знайти використання BuildBot та в архівах кодів Google.
Так яка ж логіка людей, які використовують Buildbot? Адже є інші інструменти: Круіз контроль и Дженкінс. Відповім так. Більшість завдань Дженкінс і справді буде достатньо. В свою чергу, BuildBot — більш адаптивний, при цьому завдання там вирішуються так само просто, як і в Дженкінс. Вибирати вам. Але якщо вже ми шукаємо інструмент для цільового проекту, що розвивається, то чому б не вибрати той, який дозволить, відштовхуючись від простих кроків, отримати систему складання, що має інтерактивність і унікальний інтерфейс.
У тих, чий цільовий проект написаний на python, постає питання: «Чому б не вибрати систему інтегрування, в якій є зрозумілий інтерфейс з погляду мови, яка використовується в проекті?». І тут саме час уявити переваги BuildBot.
Отже, наш інструментальний квартет. Для себе я визначив четвірку особливостей BuildBot:
- Це framework з відкритим вихідним кодом під ліцензією GPL.
- Це використання python як інструмент конфігурування та опису необхідних дій
- Це можливість отримувати відповідь з боку машини, на якій відбувається складання
- Це нарешті мінімальні вимоги до Хосту. Для розгортання потрібно python і twisted, і не потрібна віртуальна машина та java-машина.
2. Концепція на чолі з BuildMaster
Центральне місце в архітектурі розподілу завдань займає додавання Master. Він являє собою сервіс, який:
- відстежує зміни у дереві вихідників проекту
- посилає команди, які слід виконати сервісу Worker для побудови проекту та його тестування
- повідомляє користувачів про результати виконаних дій
додавання Master конфігурується через файл master.cfg. Цей файл лежить докорінно додавання Master. Пізніше я покажу, як це коріння створюється. Сам по собі файл master.cfg містить у собі python — скрипт, який використовує дзвінки BuildBot.
Наступний найважливіший об'єкт BuildBot має назву Працівник. Цей сервіс може бути запущений на іншому хості з іншого OS, а може і на тому, де додавання Master. Також він може існувати у спеціально заготовленому віртуальному середовищі зі своїми пакетами та змінними. Дані віртуальні середовища можуть бути приготовлені за допомогою python-утиліт на зразок vertualenv, venv.
додавання Master транслює команди кожному Працівник-у, а той, своєю чергою, їх виконує. Тобто виходить, що процес побудови та тестування проекту може йти на Працівник-е під керуванням Windows та іншому Worker-е під керуванням linux.
Оформлення вихідних кодів проекту відбувається на кожному Працівник-е.
3. Встановлення
Тож поїхали. Як хост я використовуватиму Ubuntu 18.04. На ньому я поміщу одного додавання Master-a та одного Працівник-a. Але спочатку потрібно встановити python3.7:
sudo apt-get update
sudo apt-get install python3.7
Для тих, кому треба python3.7.2, замість 3.7.1 можна зробити наступне:
sudo apt-get update
sudo apt-get software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get install python3.7
sudo ln -fs /usr/bin/python3.7 /usr/bin/python3
pip3 install --upgrade pip
Наступним кроком ми встановлюємо Twited и BuildBot, а також пакети, що дозволяють задіяти додатковий функціонал. BuildBot-а.
/*Все что под sudo будет установленно для всех пользователей в директорию /usr/local/lib/python3.7/dist-packages*/
#На хосте который производит мониторинг Worker-ов
sudo pip install twisted #Библиотека twisted
sudo pip install buildbot #BuildMaster
#Дополнительный функционал
pip install pysqlite3 #Устанавливаем базу sqllite в учебных целях
pip install jinja2 #framework наподобие django, для web и для почтовых рассыллок
pip install autobahn #Web cокеты для связи BuildMaster->Worker
pip install sqlalchemy sqlalchemy-migrate #Для отображения схемы базы данных
#Для Web отображения BuildBot-a
pip install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view
pip install python-dateutil #Отображение дат в web
#На стороне хоста который непосредственно осуществляет сборку и тестирование
pip install buildbot-worker #Worker
#Дополнительный функционал
sudo pip install virtualenv #Виртуальная среда
4. Перші кроки
Час створити додавання Master. Він буде у нас у папці /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемНаступний крок. Створимо Працівник. Він буде у нас у папці /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Коли ви запустите Працівник, то за умовчанням він створить у /home/habr/worker папку з назвою проекту, який вказано в master.cfg. А в татку з назвою проекту він створить директорію будувати, і далі в неї робитиме контроль. Робочим каталогом для Працівник-а стане директорія /home/habr/yourProject/build.
"Золотий ключик
А тепер те, заради чого я писав попередній абзац: скрипт, який Майстер вимагатиме у Працівник-а зробити віддалено в цій директорії, не буде виконано, оскільки скрипт не має прав для запуску. Щоб виправити ситуацію, знадобиться ключик -umask = 0o22, що накладає заборону на запис до цієї директорії, але права запуску залишить. А нам тільки це потрібно.
додавання Master и Працівник встановлюють між собою з'єднання. Трапляється, що воно обривається і Працівник деякий час чекає відповіді від додавання Master-А. Якщо відповіді не буде, підключення перезапускається. Ключ -keepalive = 60 якраз і потрібен для того, щоб вказати час, після якого з'єднуватися перезавантажується.
5. Конфігурація. Покроковий рецепт
Конфігурація додавання Master ведеться на боці машини, де ми виконували команду створити-майстер. У нашому випадку це каталог /home/habr/master. Конфігураційний файл master.cfg поки що не існує, однак сама команда вже створила файл master.cmg.sample. Необхідно перейменувати його в master.cfg.sample в master.cfg
mv master.cfg.sample master.cfgВідкриємо цей master.cfg. І розберемо те, із чого він складається. А після цього спробуємо створити власний конфігураційний файл.
master.cfg
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
name="all",
change_filter=util.ChangeFilter(branch='master'),
treeStableTimer=None,
builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
name="force",
builderNames=["runtests"]))
factory = util.BuildFactory()
factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "hello"],
env={"PYTHONPATH": "."}))
c['builders'] = []
c['builders'].append(
util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
c['services'] = []
c['title'] = "Hello World CI"
c['titleURL'] = "https://buildbot.github.io/hello-world/"
c['buildbotURL'] = "http://localhost:8010/"
c['www'] = dict(port=8010,
plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
c['db'] = {
'db_url' : "sqlite:///state.sqlite",
}
5.1 BuildmasterConfig
c = BuildmasterConfig = {} BuildmasterConfig - Базовий словник конфігураційного файлу. Він має бути обов'язково задіяний у конфігураційному файлі. Для зручності використання коду конфігурації вводиться його псевдонім "с". Назви в c[«keyFromDist»] є фіксованими елементами для взаємодії з додавання Master. Під кожен ключ як значення підставляється відповідний об'єкт.
працівники 5.2
c['workers'] = [worker.Worker("example-worker", "pass")]На цей раз ми вказуємо додавання Master-у список з Працівник-ів. Сам Працівник ми створювали , вказавши you-worker-name и пароль. Тепер їх треба вказати замість example-worker и проходити .
5.3 change_source
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
За ключом change_source словника c отримуємо доступ до списку, куди потрібно покласти об'єкт, який опитує репозиторій з кодом проекту. У прикладі використовується Git репозиторій, який опитується з деякою періодичністю.
Перший аргумент є шляхом до репозиторію.
робочий каталог є шлях до папки, де на стороні Працівник-а щодо шляху /home/habr/worker/yourProject/build буде git зберігати локальну версію репозиторію.
філія містить конкретну гілку в репозиторії, яку слід стежити.
pollInterval містить число секунд, після яких додавання Master опитуватиме репозиторій на наявність змін.
Є кілька методів відслідковувати зміни у репозиторії проекту.
Найпростіший метод - це Опитування, який має на увазі, що додавання Master періодично опитує сервер із репозиторієм. У разі якщо commit відбив зміни в репозиторії, то додавання Master з деякою затримкою створить внутрішній об'єкт Редагувати і направить його в обробник подій Планувальник, який і запустить кроки зі складання та тестування проекту на Працівник-е. Серед цих кроків буде вказано оновлення репозиторію. Саме на Працівник-е утвориться локальна копія репозиторію. Деталі цього процесу будуть розкриті нижче у наступних двох розділах ( и ).
Ще більш витонченим методом відстеження змін у репозиторії є пряме відправлення повідомлень від сервера, на якому він розміщений, додавання Master-у про зміну вихідних кодів проекту В цьому випадку, як тільки розробник зробить commit, сервер з репозиторієм проекту надішле повідомлення додавання Master-у. А той, у свою чергу, його перехопить, створивши об'єкт PBChangeSource. Далі цей об'єкт буде передано до Планувальник, який і активує кроки зі збирання проекту та його тестування. Важлива частина цього способу ця робота з гачок-Скриптами сервера в репозиторії У скрипті гачок-а, що відповідає за обробку дій при commit-е, необхідно викликати утиліту sendchange та вказати мережеву адресу додавання Master-А. Вказати потрібно і мережевий порт, який слухатиме PBChangeSource. PBChangeSource, до речі, є частиною додавання Master-А. Це метод вимагатиме права адмін-a на сервері, де розташований репозиторій проекту. Попередньо потрібно зробити backup репозиторію.
5.4 shedulers
c['schedulers'] = []
c['schedulers'].append(schedulers.SingleBranchScheduler(
name="all",
change_filter=util.ChangeFilter(branch='master'),
treeStableTimer=None,
builderNames=["runtests"]))
c['schedulers'].append(schedulers.ForceScheduler(
name="force",
builderNames=["runtests"]))
планувальники – це елемент, який виступає тригером, який запускає весь ланцюжок складання та тестування проекту.
Ті зміни, що були зафіксовані change_source, перетворилися у процесі роботи BuildBot-a в об'єкт Редагувати і тепер кожне Sheduler на їх основі будує запити на запуск процесу збирання проекту. Однак він визначає і те, коли ці запити передати далі у чергу. Об'єкт Будівельник зберігає в собі чергу запитів та відстежує стан поточного складання на окремому Працівник-е. Будівельник існує і на додавання Master-e і на Працівник-e. Він же посилає з додавання Master-а на Працівник-А вже конкретний будувати - Серію кроків, яку слід виконати.
Ми бачимо, що у поточному прикладі таких планувальники створюється 2 штуки. Причому кожна має свій тип.
SingleBranchScheduler – один із найпопулярніших класів розкладу. Він спостерігає за однією гілкою і спрацьовує за зафіксованою зміною у ній. Коли він бачить зміни, може відкласти відправку запиту на побудову (відкласти на період, зазначений у спеціальному параметрі treeStableTimer). В ім'я задається ім'я розкладу, який відображатиметься в BuildBot-web-інтерфейс. У ChangeFilter задається фільтр, пройшовши який зміни у гілці спонукають розклад надіслати запит на побудову. У builderNames вказується ім'я будівельник-a, яке ми поставимо трохи пізніше. Ім'я в нашому випадку буде те саме, що й ім'я проекту: yourProject.
ForceScheduler дуже проста штука. Цей вид розкладу спрацьовує по клацанню миші через BuildBot-web-інтерфейс. Параметри мають ту саму суть, що і в SingleBranchScheduler.
PS №3. Раптом знадобиться
Періодична - Це розклад, який спрацьовує з певною фіксованою за часом періодичністю. Виглядає виклик його приблизно так
from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
builderNames=["full-solaris"],
periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]
5.5 BuildFactory
factory = util.BuildFactory()
factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental'))
factory.addStep(steps.ShellCommand(command=["trial", "hello"],
env={"PYTHONPATH": "."}))
periodicBuildTimer задає час цієї періодичності за секунди.
BuildFactory створює конкретний будувати, який потім будівельник відсилає на Працівник. У BuildFactory вказуються кроки, які слід виконати Працівник-у. Кроки додаються за допомогою методу виклику addStep
Перший доданий крок у цьому прикладі git clean -d -f -f -x, Потім git перевірка. Ці дії закладені у параметрі метод, який наочно не вказаний, але має значення за замовчуванням свіжий. Параметр mode='incremental' говорить про те, що файли з директорії, куди робиться chechout, при цьому відсутні в репозиторії, залишаються недоторканими.
Другий доданий крок – це виклик скрипту суд з параметром привіт на стороні Працівник-а з директорії /home/habr/worker/yourProject/build c змінної оточення PATHONPATH=… Таким чином, ви можете писати свої скрипти та виконувати їх на стороні Працівник-a через крок util.ShellCommand. Дані скрипти можна покласти у репозиторій. Тоді при chechout-е вони потраплятимуть у /home/habr/worker/yourProject/build. Однак тоді є два «але»:
- Працівник має бути створено з ключем для того, щоб він не блокував права на виконання після контроль-а.
- При git push-е цих скриптів необхідно вказати властивість exacutableщоб потім при chechout-e права виконання скрипта Git не втратив.
5.6 будівельників
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Що таке Будівельник було розказано . Зараз я докладніше розповім про те, як його створити. BuilderConfig є конструктором будівельник. Таких конструкторів у c['builders'] можна задати кілька, оскільки це лист об'єктів будівельник типу. Зараз трохи перепишемо приклад від BuildBot, наблизивши його до нашого завдання.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Тепер розповім про параметри BuilderConfig.
ім'я задає ім'я будівельник-a. Тут ми назвали його yourProject. Це означає, що на Працівник-е буде створено цей шлях /home/habr/worker/yourProject/build. Sheduler шукає будівельник саме по цьому імені.
workernames містить лист Працівник-ів. Кожен з яких повинен бути доданий до c['workers'].
завод - конкретний будувати, з яким асоційовано будівельник. Він надішле об'єкт будувати на Працівник для виконання всіх кроків, що входять до складу цього будувати-а.
6. Приклад своєї конфігурації
Ось архітектура прикладу проекту, яку я пропоную реалізувати через BuildBot
.
Як систему контролю версіями будемо використовувати svn. Сам репозиторій буде в якійсь хмарі. Ось адреса цієї хмари . У хмарі під svn є обліковий запис username: користувач, passwd: пароль. Скрипти, які являють собою кроки будувати-a будуть також лежати у гілці svn, в окремій папці buildbot/worker_linux. Ці скрипти лежать у репозиторії зі збереженою властивістю виконуваний файл.
додавання Master и Працівник працюють на одному хості project.host .додавання Master зберігає свої файли у папці /home/habr/master. Працівник ж зберігає наступним шляхом /home/habr/worker. Зв'язок процесів додавання Master-а та Працівник-а ведеться через 4000 порт за протоколом BuildBot-a, тобто 'pb' протокол.
Цільовий проект повністю написаний на python-і. Завдання відстежити його зміни, створити executable файл, згенерувати документацію, провести тестування. У разі failure потрібно всім розробникам надіслати повідомлення на пошту про те, що є невдало виконана дія.
Web відображення BuildBot ми підключимо на 80 порт для project.host. Apatch ставити необов'язково. У складі бібліотеки скручений вже є web сервер, BuildBot його використовує.
Для зберігання інформації внутрішнього призначення для BuildBot будем використовувати sqlite.
Для поштового розсилання потрібен хост smtp.your.domain — на ньому дозволено надсилання листів з пошти [захищено електронною поштою] без автентифікації. Також на хості 'SMTP ' протокол слухається на посту 1025.
Задіяних осіб у процесі двоє: адмін и користувач. admin адмініструє BuildBot. user є особою, яка здійснює commit-и.
Exacutable файл генерується через pyinstaller. Документація генерується через доксиген.
Для цієї архітектури я написав ось такий master.cfg:
master.cfg
import os, re
from buildbot.plugins import steps, util, schedulers, worker, changes, reporters
c= BuildmasterConfig ={}
c['workers'] = [ worker.Worker('yourWorkerName', 'password') ]
c['protocols'] = {'pb': {'port': 4000}}
svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk",
svnuser="user",
svnpasswd="password",
pollinterval=60,
split_file=util.svn.split_file_alwaystrunk
)
c['change_source'] = svn_poller
hourlyscheduler = schedulers.SingleBranchScheduler(
name="your-project-schedulers",
change_filter=util.ChangeFilter(branch=None),
builderNames=["yourProject"],
properties = {'owner': 'admin'}
)
c['schedulers'] = [hourlyscheduler]
checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk',
mode='full',
method='fresh',
username="user",
password="password",
haltOnFailure=True)
projectHost_build = util.BuildFactory()
cleanProject = steps.ShellCommand(name="Clean",
command=["buildbot/worker_linux/pyinstaller_project", "clean"]
)
buildProject = steps.ShellCommand(name="Build",
command=["buildbot/worker_linux/pyinstaller_project", "build"]
)
doxyProject = steps.ShellCommand(name="Update Docs",
command=["buildbot/worker_linux/gendoc", []]
)
testProject = steps.ShellCommand(name="Tests",
command=["python","tests/utest.py"],
env={'PYTHONPATH': '.'}
)
projectHost_build.addStep(checkout)
projectHost_build.addStep(cleanProject)
projectHost_build.addStep(buildProject)
projectHost_build.addStep(doxyProject)
projectHost_build.addStep(testProject)
c['builders'] = [
util.BuilderConfig(name="yourProject", workername='yourWorkerName', factory=projectHost_build)
]
template_html=u'''
<h4>Статус построенного релиза: {{ summary }}</h4>
<p>Используемый сервис для постраения: {{ workername }}</p>
<p>Проект: {{ projects }}</p>
<p>Для того что бы посмотреть интерфейс управления пройдите по ссылке: {{ buildbot_url }}</p>
<p>Для того что бы посмотреть результат сборки пройдите по ссылке: {{ build_url }}</p>
<p>Используя WinSCP можно подключиться к серверу c ip:xxx.xx.xxx.xx. Войдя под habr/password, забрать собранный executable файл с директории ~/worker/yourProject/build/dist.</p>
<p><b>Построение было произведено через Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="[email protected]",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['[email protected]'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
c['title'] = "The process of bulding"
c['titleURL'] = "http://project.host:80/"
c['buildbotURL'] = "http://project.host"
c['www'] = dict(port=80,
plugins=dict(waterfall_view={}, console_view={}, grid_view={}))
c['db'] = {
'db_url' : "sqlite:///state.sqlite"
}
Для початку необхідно додавання Master-а та Працівник-a. Потім вставити цей файл master.cfg в /home/habr/master.
Наступним кроком потрібно запустити службу додавання Master-а
sudo buildbot start /home/habr/master
Потім запустити службу Працівник-a
buildbot-worker start /home/habr/worker
Готово! Тепер Buildbot буде відстежувати зміни та спрацьовувати за commit-у в svn, виконуючи кроки складання та тестування проекту з вказаною вище архітектурою.
Нижче я розпишу деякі особливості вищезгаданого master.cfg.
6.1 На шляху до свого master.cfg
Під час написання свого master.cfg буде зроблено чимало помилок, тому знадобиться читання log-файлу. Він зберігається як на додавання Master-ec абсолютним шляхом /home/habr/master/twistd.log, так і на стороні Працівник-a з абсолютним шляхом /home/habr/worker/twistd.log. У міру читання помилки та її виправлення потрібно перезавантаження служби додавання Master-a. Ось як це робиться:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Робота з svn
svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk",
svnuser="user",
svnpasswd="password",
pollinterval=60,
split_file=util.svn.split_file_alwaystrunk
)
c['change_source'] = svn_poller
hourlyscheduler = schedulers.SingleBranchScheduler(
name="your-project-schedulers",
change_filter=util.ChangeFilter(branch=None),
builderNames=["yourProject"],
properties = {'owner': 'admin'}
)
c['schedulers'] = [hourlyscheduler]
checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk',
mode='full',
method='fresh',
username="user",
password="password",
haltOnFailure=True)
Для початку поглянемо на svn_poller. Це все той же інтерфейс, який регулярно опитує репозиторій раз на хвилину. В даному випадку svn_poller звертається лише до гілки ствол. Загадковий параметр split_file=util.svn.split_file_alwaystrunk задає правила: як розбивати структуру папок svn на гілки. Він пропонує їм відносні шляхи. В свою чергу split_file_alwaystrunk спрощує процес, говорячи про те, що в репозиторії тільки ствол.
В Планувальники вказується ChangeFilter, який бачить ніхто та асоціює з ним гілку ствол по заданій асоціації через split_file_alwaystrunk. Реагуючи на зміни в ствол, запускає будівельник з ім'ям yourProject.
властивості тут потрібен для того, щоб адмін отримував розсилку у результатах складання та тестування як власник процесу.
Крок будувати-a контроль здатний робити повне видалення будь-яких файлів, що лежать у локальній версії репозиторію. Працівник-А. А потім робити повний svn оновлення. Режим налаштовано через параметр mode=full, method=fresh. Параметр haltOnTailure говорить про те, що якщо svn оновлення буде виконано з помилкою, весь процес складання і тестування слід призупинити, оскільки подальші дії не мають сенсу.
6.3 Вам листа: reporters уповноважений заявити
журналістам - Це сервіс розсилки повідомлень на пошту.
template_html=u'''
<h4>Статус построенного релиза: {{ summary }}</h4>
<p>Используемый сервис для постраения: {{ workername }}</p>
<p>Проект: {{ projects }}</p>
<p>Для того что бы посмотреть интерфейс управления пройдите по ссылке: {{ buildbot_url }}</p>
<p>Для того что бы посмотреть результат сборки пройдите по ссылке: {{ build_url }}</p>
<p>Используя WinSCP можно подключиться к серверу c ip:xxx.xx.xxx.xx. Войдя под habr/password, забрать собранный executable файл с директории ~/worker/yourProject/build/dist.</p>
<p><b>Построение было произведено через Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="[email protected]",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['[email protected]'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
Він може розсилати повідомлення .
MailNotifier використовує пошту для надсилання повідомлень.
template_html дає шаблон тексту для розсилки. Для створення розмітки використовується HTML. Він модифікований двигуном (можна порівняти з django). BuildBot має набір змінних, значення яких підставляються шаблон в процесі формування тексту повідомлення. Ці змінні вписані {{ подвійні фігурні дужки }}. Так наприклад, резюме виводить статус виконаних операцій, тобто success або failure. А проектів виведе yourProject. Так, за допомогою керуючих команд у jinja2, змінних BuildBot-а засобів форматування рядків python можна створити цілком інформативне повідомлення.
MailNotifier містить такі аргументи.
fromaddr – адреса, з якої всім надходитиме розсилка.
sendToInterestedUsers=True надсилає повідомлення власнику та користувачу, який зробив commit.
пошук - Суфікс, який треба додати до імен користувачів, які отримують розсилку. Так адмін як користувач отримає розсилку на адресу [захищено електронною поштою].
relayhost задає ім'я хоста, на якому відкрито сервер SMTP, то smptPort задає номер порту, який слухає SMTP сервер.
mode=«warning» каже, що розсилку потрібно робити лише у разі наявності хоча б одного кроку будувати-а, який закінчився зі статусом failure чи warning. У разі успіху розсилку робити не потрібно.
extraRecipients містить список осіб, кому слід зробити розсилку крім власника та особи, яка здійснила commit.
messageFormatter є об'єктом, що задає формат повідомлення, його шаблон, і набір змінних доступних з jinja2. Такі параметри, як wantProperties=True и wantSteps=True задають цей набір доступних змінних.
з['services']=[sendMessageToAll] надає список сервісів, серед яких і буде наш репортер.
Ми зробили це! Мої вітання
Ми створили власну конфігурацію та побачили функціонал, на який здатний BuildBot. Цього, гадаю, достатньо для того, щоб зрозуміти, чи потрібен цей інструмент для створення вашого проекту. Він вам цікавий? Він вам знадобиться? З ним зручно працювати? Тоді я писати цю статтю не дарма.
І ще. Хотілося б, щоб професійна спільнота, що використовує BuildBot, Стало ширше, мануали перекладалися, і прикладів ставало ще більше.
Всім дякую за увагу. Успіхів.
Джерело: habr.com