(Изображение от from
Здравейте!
Казвам се Евгений Черкин, аз съм програмист в екипа за разработка на миннодобивната компания Polymetal.
Започвайки с всеки голям проект, започваш да се замисляш: „Кой софтуер е най-добре да се използва за неговото обслужване?“ Проектът по информационни технологии преминава през редица етапи преди пускането на нова версия. Добре е, когато веригата от тези етапи е автоматизирана. Самият автоматизиран процес на издаване на нова версия на IT-проекта се нарича Continuous Integration. BuildBot ни се оказа добър помощник, реализиращ този процес.
В тази статия реших да представя преглед на възможностите BuildBot. Какво може да направи този софтуер? Как да се подходи към него и как да се изградят нормални ЕФЕКТИВНИ РАБОТНИ ОТНОШЕНИЯ? Опитът ни можете да приложите и вие, създавайки на вашия компютър работна услуга за сборка и тестване на вашия проект.
Съдържание
Съдържание
1. Защо BuildBot?
По-рано на habr-e срещах статии за реализирането на Continuous Integration с използването на BuildBot. Например, ми се стори най-информативна. Има и друг пример — . Тези статии могат да бъдат подправени , а за допълнение, на английски език. В комбинация всява добра отправна точка. След като прочетете тези статии, вие несъмнено ще искате веднага да направите нещо на BuildBot .
Стоп! Някой изобщо е използвал ли го в своите проекти? Оказва се, че да, го приложиха в задачите си. Могат да се намерят използването BuildBot и в архивите на кодовете на Google.
Каква е тогава логиката на хората, които използват Buildbot? Ведь есть другие инструменты: CruiseControl и Jenkins. Отговарям така. За повечето задачи Jenkins действително ще е достатъчно. От своя страна, BuildBot е по-адаптивен, като задачите там се решават също толкова лесно, колкото и в Jenkins. Изборът е ваш. Но тъй като търсим инструмент за развиващ се целеви проект, защо да не изберем този, който ще позволи, основавайки се на прости стъпки, да получим система за сборка с интерактивност и уникален интерфейс.
У тези, чийто целеви проект е написан на python, възниква въпросът: „Защо да не изберем система за интеграция, в която има ясен интерфейс от гледна точка на езика, използван в проекта?“. И тук е времето да представим предимствата BuildBot.
И така, нашият "инструментален квартет". За себе си определих четирите особености BuildBot:
- Това е фреймуърк с отворен код под лицензия GPL
- Това е използването на python като инструмент за конфигуриране и описание на необходимите действия
- Това е възможността да получаваме отговор от машината, на която протича сглобяването
- Това, накрая, минималните изисквания към хоста. За разгръщане се изискват python и twisted, и не се нуждае от виртуална машина или java-машина.
2. Концепция начело с BuildMaster
Централно място в архитектурата на разпределението на задачите заема BuildMaster. Той представлява услуга, която:
- наблюдава промените в дървото на изходния код на проекта
- изпраща команди, които трябва да изпълни услугата Worker за изграждане на проекта и тестването му
- уведомява потребителите за резултатите от извършените действия
BuildMaster конфигурира се чрез файл master.cfg. Този файл се намира в корена BuildMaster. По-късно ще покажа как се създава този корен. Самият файл master.cfg съдържа python — скрипт, който използва извиквания BuildBot.
Следващият най-важен обект BuildBot има име Worker. Тази услуга може да бъде пусната на друг хост с друга ОС, но и на този, на който BuildMaster. Тя може също да съществува в специално приготвена виртуална среда с свои пакети и променливи. Тези виртуални среди могат да бъдат приготвени с помощта на python-полезни утилити, като vertualenv, venv.
BuildMaster превежда командите на всеки Worker-у, а той, от своя страна, ги изпълнява. Тоест, става така, че процесът на изграждане и тестване на проекта може да протича на Worker-е под управлението на Windows и на друг Worker под управлението на linux.
Сheckout на изходния код на проекта става на всеки Worker-е.
3. Инсталиране
И така, да започнем. Като хост ще използвам Ubuntu 18.04. На него ще разположа един BuildMaster-a и един Worker-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 install 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
Следващата стъпка е да инсталираме Twisted и BuildBot, и пакети, позволяващи активиране на допълнителен функционал BuildBot-a.
/*Все что под 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. Първи стъпки
Време е да създадете BuildMaster. Той ще бъде в нашата папка /home/habr/master.
mkdir master
buildbot create-master master # Всъщност тук го създавамеСледваща стъпка. Ще създадем Worker. Той ще бъде в нашата папка /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Когато стартирате Worker, по подразбиране той ще създаде в /home/habr/worker папка с името на проекта, който е указан в master.cfg. А в папката с името на проекта той ще създаде директория build, и после в нея ще прави checkout. Работната директория за Worker-а ще бъде директория /home/habr/yourProject/build.
«Златен» ключ
А сега за нещото, за което написах предишния абзац: скрипт, който Master ще изиска от Worker-а да извърши операции отдалечено в тази директория, няма да бъде изпълнен, тъй като скриптът няма права за стартиране. За да се поправи ситуацията, ще е нужен ключ —umask=0o22, който налага забрана за запис в тази директория, но ще запази правата за изпълнение. А точно това ни е нужно.
BuildMaster и Worker установяват връзка помежду си. Понякога тя се разкъсва и Worker изчаква известно време отговор от BuildMaster-а. Ако отговор не последва, връзката се презарежда. Ключът —keepalive=60 е точно това, от което се нуждаем, за да укажем времето, след което connect се презарежда.
5. Конфигурация. Стъпка по стъпка рецепта
Конфигурация BuildMaster се извършва от страната на машината, където изпълнихме командата create-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»] са фиксирани елементи за взаимодействие с BuildMaster. За всеки ключ като стойност се подставя съответният обект.
5.2 workers
c['workers'] = [worker.Worker("example-worker", "pass")]Този път посочваме BuildMaster- списък от Worker-и. Самият Worker създадохме , като посочихме your-worker-name и парола. Сега също трябва да посочим вместо example-worker и pass .
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 репозиторий, който се опитва да получи информация периодично.
Първият аргумент е пътят до вашия репозиторий.
workdir представлява пътя до папката, където от страна на Worker-а относно пътя /home/habr/worker/yourProject/build git ще съхранява локалната версия на репозитория.
branch съдържа конкретна клонка в репозитория, която трябва да се следи.
pollInterval съдържа брой секунди, след които BuildMaster ще опитва да получи информация от репозитория за промени.
Има няколко метода за следене на промените в репозитория на проекта.
Най-простият метод е Polling, който предполага, че BuildMaster периодично запитва сървъра с хранилището. В случай, че commit отрази промените в хранилището, BuildMaster с известно закъснение ще създаде вътрешен обект Change и ще го изпрати на обработчика на събития Scheduler, който ще стартира стъпките за компилиране и тестване на проекта на Worker-а. Сред тези стъпки ще бъде посочено актуализиране хранилището. Точно на Worker-а ще се създаде локална копия на хранилището. Подробности за този процес ще бъдат разкрити по-долу в следващите два раздела ( и ).
Още по-изискан метод за проследяване на промените в хранилището е директното изпращане на съобщения от сървъра, на който е хранилището, към BuildMaster-а за промяна на изходния код на проекта. В този случай, веднага щом разработчикът направи commit, сървърът на проекта с хранилището ще изпрати съобщение на BuildMaster-а. А той, от своя страна, ще го прихване, създавайки обект PBChangeSource. След това този обект ще бъде предаден на Scheduler, който ще активира стъпките за компилиране на проекта и неговото тестване. Важна част от този метод е работата с hook-скриптовете на сървъра в хранилището. В скрипта hook-а, отговарящ за обработката на действия при commit-а, е необходимо да се извика утилитата sendchange и да се посочи мрежовия адрес на BuildMaster-а. Трябва да се посочи и мрежовия порт, който ще слуша PBChangeSource. PBChangeSource, което, между другото, е част от BuildMaster-а. Този метод ще изисква права админ-а на сървъра, където е разположено хранилището на проекта. Предварително трябва да се направи резервно копие на хранилището.
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"]))
schedulers – това е елемент, който действа като тригер, стартиращ цялата верига от компилиране и тестване на проекта.
Тези промени, които бяха регистрирани change_source, се преобразуваха в процеса на работа BuildBot-а в обект Change и сега всеки Scheduler на тяхна база изгражда заявки за стартиране на процеса на компилиране на проекта. Въпреки това, той определя и кога да предаде тези заявки по-нататък в опашката. Обектът Builder съхранява опашката от заявки и проследява състоянието на текущата компилация на отделен Worker-е. Builder съществува и на BuildMaster-е и на Worker-е. Той също така изпраща с BuildMaster-а на Worker-а вече конкретен build — серия от стъпки, които трябва да се изпълнят.
Виждаме, че в текущия пример такива schedulers се създават 2 броя. Освен това, всеки има свой тип.
SingleBranchScheduler – един от най-популярните класове за график. Той следи една клонка и се активира при зададена промяна в нея. Когато види промени, може да отложи изпращането на заявка за изграждане (да я отложи за период, указан в специален параметър treeStableTimer). В име се задава името на графика, което ще се показва в BuildBot-уеб-интерфейса. В ChangeFilter се задава филтър, след който промените в клонката подтикват графика да изпрати заявка за изграждане. В builderNames се указва името builder-а, което ще зададем малко по-късно. Името в нашия случай ще бъде същото като името на проекта: yourProject.
ForceScheduler е доста проста работа. Този вид график се активира с щракване на мишката през BuildBot-уеб-интерфейса. Параметрите имат същата същност, както в SingleBranchScheduler.
P.S. №3. Може би ще е полезно
Periodic — това е график, който се активира с определена фиксирана по време периодичност. Извикването му изглежда приблизително така:
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 създава конкретен build, който след това builder изпраща на Worker. В BuildFactory се указват стъпките, които трябва да се изпълнят Worker-у. Стъпките се добавят чрез извикване на метода addStep
Първата добавена стъпка в този пример — git clean -d -f -f –x, след което git checkout. Тези действия са заложени в параметъра method, който явно не е указан, но подразбира подразбирано значение fresh. Параметър mode=’incremental’ казва, че файловете от директорията, в която се прави chechout, при това отсъстващите в репозитория остават непокътнати.
Втората добавена стъпка — това е извикването на скрипт trial с параметъра hello на страната Worker-а от директория /home/habr/worker/yourProject/build c с променлива на средата PATHONPATH=… Така можете да пишете свои скриптове и да ги изпълнявате на страната Worker-а чрез стъпка util.ShellCommand. Тези скриптове могат да бъдат положени директно в репозитория. Тогава при chechout-е те ще попадат в /home/habr/worker/yourProject/build. Въпреки това, има две "но":
- Worker трябва да бъде създаден с ключа за да не блокира правата за изпълнение след checkout-a.
- При git push-е тези скриптове е необходимо да се укаже свойството exacutable, за да не загуби правото за изпълнение на скрипта Git след chechout-е.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
За това какво е Builder беше разказано . Сега ще разкажа по-подробно как да го създадете. BuilderConfig е строител builder. Може да зададете няколко от тези строители в c[‘builders’] , тъй като това е списък с обекти builder от тип. Сега ще пренапишем примера от BuildBot, приближавайки го до нашата задача.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Сега ще разкажа за параметрите BuilderConfig.
име задава името builder-a. Тук го нарекохме yourProject. Това означава, че на Worker-е ще бъде създаден този път /home/habr/worker/yourProject/build. Scheduler намира builder точно по това име.
workernames съдържа списък Worker-и. Всеки от тях трябва да бъде добавен в c[‘workers’].
factory — конкретно build, с което е асоцииран builder. То ще изпрати обект build на Worker за изпълнение на всички стъпки, включващи се в това build-a.
6. Пример за собствена конфигурация
Ето архитектурата на примера на проекта, която предлагам да реализираме чрез BuildBot
.
Като система за контрол на версиите ще използваме svn. Самият репозиторий ще се намира в облака. Ето адреса на този облак . В облака под svn има акаунт username: потребител, passwd: парола. Скриптовете, които представляват стъпките build-a ще се намират също в клона svn, в отделна папка buildbot/worker_linux. Тези скриптове са в репозитория с запазено свойство executable.
BuildMaster и Worker работят на един хост project.host .BuildMaster съхранява файловете си в папка /home/habr/master. Worker също съхранява по следния път /home/habr/worker. Връзката между процесите BuildMaster-а и Worker-а се извършва чрез порт 4000 по протокола BuildBot-a, тоест ‘pb’ протокол.
Целият целеви проект е написан на python. Задачата е да следи промените, да създава executable файл, да генерира документация, да проведе тестване. В случай на неуспех е необходимо на всички разработчици да се изпрати имейл с информация за неуспешното действие.
Уеб представянето BuildBot ще бъде свързано на порт 80 за project.host. Apatch не е задължителен. В библиотеката twisted вече има уеб сървър, BuildBot който използва.
За съхранение на информация с вътрешно назначение за BuildBot ще използваме sqlite.
За имейл разпратки е необходим хост smtp.your.domain — там е разрешена изпращането на писма от имейл projectHost@your.domain без аутентификация. Също така на хоста ‘smtp ‘, протоколът се слуша на порт 1025.
Засегнатите лица в процеса са двама: админ и потребител. admin администрира BuildBot. user е лицето, което извършва commit-и.
Exacutable файл се генерира чрез pyinstaller. Документацията се генерира чрез doxygen.
За данната архитектура написах следното master.cfg:
master.cfg
импорт os, re
от buildbot.plugins импорт стъпки, util, разписания, работник, променя, репортери
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 можете да се свържете със сървъра с ip:xxx.xx.xxx.xx. Влезте с habr/password, за да изтеглите събрания изпълним файл от директорията ~/worker/yourProject/build/dist.</p>
<p><b>Изграждането беше извършено чрез Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['user@your.domain'],
messageFormatter=reporters.MessageFormatter(
template=template_html,
template_type='html',
wantProperties=True,
wantSteps=True)
)
c['services'] = [sendMessageToAll]
c['title'] = "Процесът на изграждане"
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"
}
Първо е необходимо BuildMaster-а и Worker-a. След това да се встави този файл master.cfg в /home/habr/master.
Следващата стъпка е да се стартира услугата BuildMaster-а
sudo buildbot start /home/habr/master
След това стартирайте услугата Worker-a
buildbot-worker start /home/habr/worker
Готово! Сега Buildbot ще следи за изменения и ще реагира по commit-у в svn, изпълнявайки стъпките за изграждане и тестване на проекта с горепосочената архитектура.
По-долу ще опиша някои особености на посоченото master.cfg.
6.1 На пътя към своя master.cfg
По време на написването на своето master.cfg ще бъдат направени много грешки, така че ще е необходимо да се прочете log-файла. Той се съхранява както на BuildMaster-e c с абсолютен път /home/habr/master/twistd.log, така и от страна на Worker-a с абсолютен път /home/habr/worker/twistd.log. По време на четенето на грешките и тяхното отстраняване ще е необходимо да се рестартира услугата BuildMaster-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 се обръща само към клон trunk. Загадъчният параметър split_file=util.svn.split_file_alwaystrunk определя правилата: как да се разбива структурата на папките svn на клонове. Той предлага относителни пътища. От своя страна split_file_alwaystrunk опрощава процеса, твърдейки, че в репозитория има само trunk.
В Schedulers се отбелязва ChangeFilter, който вижда Няма и свързва с него клона trunk чрез зададената асоциация split_file_alwaystrunk. Реагирайки на изменения в trunk, стартира builder c с името yourProject.
properties тук е необходимо, за да админът получава известия за резултатите от изграждането и тестването като собственик на процеса.
Стъпка build-a checkout може да извърши пълно изтриване на всякакви файлове, лежащи в локалната версия на репозитория Worker-а. И след това да направи пълен svn update. Режимът е настроен чрез параметъра mode=full, method=fresh. Параметър haltOnTailure показва, че ако svn update ако бъде извършен с грешка, целият процес на сглобяване и тестване трябва да бъде преустановен, тъй като следващите действия нямат смисъл.
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 можете да се свържете със сървъра с ip:xxx.xx.xxx.xx. Влезте с habr/password, за да изтеглите събрания изпълним файл от директорията ~/worker/yourProject/build/dist.</p>
<p><b>Изграждането беше извършено чрез Buildbot</b></p>
'''
sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain",
sendToInterestedUsers=True,
lookup="your.domain",
relayhost="smtp.your.domain",
smtpPort=1025,
mode="warnings",
extraRecipients=['user@your.domain'],
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.
lookup — суфикс, който трябва да се добави към имената на потребителите, получаващи разпращането. Така админ че потребителят ще получи разпращането на адрес admin@your.domain.
relayhost определя името на хоста, на който е открит сървъра smtp, a smptPort определя номера на порта, който слуша smtp сървър.
mode=«warning» казва, че разпращането трябва да се извършва само при наличие на поне една стъпка build-а, която е завършила със статус failure или warning. В случай на success разпращането не е необходимо.
extraRecipients съдържа списък на лицата, на които трябва да се направи разпращането, освен собственика и лицето, извършило commit.
messageFormatter е обект, който определя формата на съобщението, неговия шаблон и набор от променливи, достъпни от jinja2. Такива параметри, като wantProperties=True и wantSteps=True определят този набор от достъпни променливи.
с[‘services’]=[sendMessageToAll] предоставя списък на услугите, сред които ще бъде нашият репортер.
Успяхме! Мои поздравления
Създадохме собствена конфигурация и видяхме функционалността, на която е способен BuildBot. Това, мисля, е достатъчно, за да разберете дали този инструмент е необходим за вашия проект. Интересен ли ви е? Ще ви бъде ли полезен? Удобно ли е да работите с него? Тогава не съм написал тази статия напразно.
И още. Желая професионалната общност, използваща BuildBot, да стане по-широка, ръководствата да се превеждат и примери да се предоставят още повече.
Благодаря на всички за вниманието. Успех.
Източник: habr.com
