(Слика од од
Здраво!
Моето име е Евгениј Черкин, јас сум програмер во развојниот тим во рударска компанија Полиметал.
Кога започнувате некој голем проект, почнувате да размислувате: „Кој софтвер е најдобар да се користи за негово сервисирање? Еден ИТ проект поминува низ неколку фази пред да ја објави следната верзија. Добро е кога синџирот на овие фази е автоматизиран. Автоматизираниот процес на објавување на нова верзија на самиот ИТ проект се нарекува Континуирана интеграција. BuildBot се покажа како добар асистент за нас во спроведувањето на овој процес.
Во оваа статија решив да дадам преглед на можностите BuildBot. За што е способен овој софтвер? Како да му пристапиме и како да изградиме нормален ЕФЕКТИВЕН РАБОТЕН ОДНОС со него? Нашето искуство можете сами да го примените со создавање работна услуга за градење и тестирање на вашиот проект на вашата машина.
содржина
содржина
1. Зошто BuildBot?
Претходно на хабр-е наидов на статии за имплементација Континуирана интеграција користење BuildBot. На пример, Го најдов најинформативно. Има уште еден пример - . Овие написи може да се зачинуваат И после тоа на англиски. Купето е добра почетна точка. Откако ќе ги прочитате овие написи, веројатно веднаш ќе посакате нешто BuildBot направи.
Стоп! Дали некој навистина го користел во своите проекти? Излегува да го применуваат во своите задачи. Може да се најде користат BuildBot и во архивите со кодови на Google.
Па која е логиката на луѓето да користат Buildbot? На крајот на краиштата, постојат и други алатки: CruiseControl и Џенкинс. Ќе одговорам вака. За повеќето задачи Џенкинс и вистината ќе биде доволна. Од своја страна, BuildBot - поадаптивни, додека проблемите таму се решаваат едноставно како и во Џенкинс. Изборот е твој. Но, бидејќи бараме алатка за развој на целен проект, зошто да не избереме една која ќе овозможи, почнувајќи од едноставни чекори, да добиеме систем за градење кој има интерактивност и единствен интерфејс.
За оние чиј целен проект е напишан во python, се поставува прашањето: „Зошто да не изберете систем за интеграција кој има јасен интерфејс во однос на јазикот што се користи во проектот? И сега е време да ги претставиме придобивките BuildBot.
Значи, нашиот „инструментален квартет“. За себе, идентификував четири карактеристики BuildBot:
- Тоа е рамка со отворен код под лиценца GPL
- Ова е употребата на python како алатка за конфигурација и опис на потребните дејства
- Ова е можност да добиете одговор од машината на која се одвива склопувањето
- Ова се, конечно, минималните барања за домаќин. Распоредувањето бара питон и извртено, а не бара виртуелна машина и java машина.
2. Концепт предводен од BuildMaster
Централно место во архитектурата на дистрибуција на задачи е BuildMaster. Тоа е услуга која:
- песни промени во дрвото на изворот на проектот
- испраќа команди кои треба да ги изврши услугата Worker за да го изгради проектот и да го тестира
- известува корисниците за резултатите од преземените активности
BuildMaster конфигуриран преку датотека господар.cfg. Оваа датотека е во коренот BuildMaster. Подоцна ќе покажам како се создава овој корен. Самата датотека господар.cfg содржи питон скрипта што користи повици BuildBot.
Следниот најважен предмет BuildBot има име Работник. Оваа услуга може да се стартува на друг домаќин со различен оперативен систем, или можеби на оној каде што BuildMaster. Може да постои и во специјално подготвена виртуелна средина со свои пакети и променливи. Овие виртуелни средини може да се подготват со користење на алатки за python како виртуеленв, венв.
BuildMaster емитува команди до сите Работник-y, а тој пак ги исполнува. Односно, излегува дека процесот на градење и тестирање на проект може да продолжи Работник-е со Windows и на друг Worker со Linux.
Исплата изворните кодови на проектот се појавуваат на секој Работник-е.
3. Инсталација
Значи, да одиме. Ќе го користам Ubuntu 18.04 како домаќин. Ќе поставам една на неа BuildMaster-а и еден Работник-а. Но, прво треба да инсталирате 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
Следниот чекор е да се инсталира Твитна и 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. Први чекори
Време за создавање BuildMaster. Ќе биде во нашата папка /дома/хабр/мајстор.
mkdir master
buildbot create-master master # Собственно сдесь и создаемСледен чекор. Ајде да создадеме Работник. Ќе биде во нашата папка /дом/хабр/работник.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Кога трчате Работник, тогаш стандардно ќе се креира во /дом/хабр/работник папка со името на проектот, која е наведена во господар.cfg. И во папката со името на проектот ќе создаде директориум се изгради, и ќе продолжи да го прави тоа исходот. Работен директориум за Работник-и ќе стане директориум /home/habr/yourProject/build.
„Златен клуч
И сега за што го напишав претходниот пасус: сценарио кое Господар ќе бара од Работник-и направено од далечина во овој директориум нема да се изврши бидејќи скриптата нема дозволи за извршување. За да ја поправите ситуацијата, ќе ви треба клуч --umask=0o22, што забранува пишување во овој директориум, но ќе ги задржи правата за стартување. И тоа е се што ни треба.
BuildMaster и Работник воспостави врска едни со други. Се случува да се откине и Работник чекајќи некое време за одговор од BuildMaster-А. Ако нема одговор, врската се рестартира. Клуч --keepalive=60 само требаше да се наведе времето после кое се поврзете се рестартира.
5. Конфигурација. Чекор по чекор рецепт
Конфигурација BuildMaster се врши на страната на машината каде што ја извршивме командата создаде-господари. Во нашиот случај, ова е директориум /дома/хабр/мајстор. Конфигурациска датотека господар.cfg сè уште не постои, но самата команда веќе ја создаде датотеката господар.cmg.примерок. Треба да го преименувате во господар.cfg.примерок в господар.cfg
mv master.cfg.sample master.cfgАјде да го отвориме овој господар.cfg. И да погледнеме од што се состои. И после тоа, ајде да се обидеме да направиме сопствена конфигурациска датотека.
господар.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 работници
c['workers'] = [worker.Worker("example-worker", "pass")]Овој пат укажуваме BuildMaster-y листа на Работник-с. Себеси Работник ние создадовме , што укажува ти-работник-име и лозинка. Сега наместо тоа треба да се наведат пример-работник и помине .
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))
Со клуч промена на изворот речник в добиваме пристап до списокот каде што сакаме да ставиме објект што го испитува складиштето со изворниот код на проектот. Примерот користи складиште на Git што се анкетира во одредени интервали.
Првиот аргумент е патот до вашето складиште.
работна дирекција ја претставува патеката до папката каде што е на страната Работник-роднина на патеката /home/habr/worker/yourProject/build git ќе ја складира локалната верзија на складиштето.
гранка содржи одредена гранка во складиштето што треба да се следи.
анкетаИнтервал го содржи бројот на секунди после кои BuildMaster ќе го анкетира складиштето за промени.
Постојат неколку методи за следење на промените во складиштето на проектот.
Наједноставниот метод е избирачки, што подразбира дека BuildMaster периодично го анкетира серверот со складиштето. Ако изврши ги одразуваше промените во складиштето, тогаш BuildMaster ќе создаде внатрешен објект со одредено задоцнување Промени и испратете го до управувачот на настани Распоредувачот, кој ќе ги започне чекорите за изградба и тестирање на проектот Работник-е. Меѓу овие чекори ќе бидат наведени ажурирање складиште. Точно на РаботникОва ќе создаде локална копија од складиштето. Деталите за овој процес ќе бидат опфатени подолу во следните два дела. ( и ).
Уште поелегантен метод за следење на промените во складиштето е да се испраќаат пораки директно од серверот што го хостира на BuildMaster- за промена на изворните кодови на проектот. Во овој случај, штом инвеститорот прави изврши, серверот со складиштето на проектот ќе испрати порака BuildMaster-y. И тој, пак, ќе го пресретне со создавање на објект PBCchangeSource. Следно, овој објект ќе биде префрлен на Распоредувачот, кој ги активира чекорите за изградба на проектот и тестирање. Важен дел од овој метод е работата со кука-серверски скрипти во складиштето. Во сценариото кука-а, одговорен за дејствија за обработка кога изврши-е, треба да се јавите во услужниот центар испрати промена и наведете ја мрежната адреса BuildMaster-А. Исто така, треба да ја наведете мрежната порта што ќе слуша PBCchangeSource. PBCchangeSource, патем, е дел BuildMaster-А. Овој метод ќе бара дозвола admin-а на серверот каде што се наоѓа складиштето на проектот. Прво ќе треба да направите резервна копија на складиштето.
5.4 распоредувачи
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"]))
распоредувачи – ова е елемент кој делува како активирач кој го започнува целиот синџир на склопување и тестирање на проектот.
Тие промени што беа евидентирани промена на изворот, трансформиран во процесот на работа BuildBot-а да приговара Промени и сега секој Шедулер врз основа на нив, гради барања за започнување на процесот на градење на проектот. Меѓутоа, исто така одредува кога овие барања ќе се префрлат понатаму на редот. Предмет Градител складира редица барања и ја следи состојбата на тековното склопување на посебна Работник-е. Градител постои на BuildMaster-е и натаму Работник-е. Тој испраќа со BuildMaster-а на Работник-и веќе конкретно се изгради - низа чекори што мора да се следат.
Гледаме дека во сегашниот пример такви распоредувачи Се создаваат 2 парчиња. Покрај тоа, секој има свој тип.
SingleBranchScheduler – еден од најпопуларните часови на распоредот. Набљудува една гранка и се активира од забележана промена во неа. Кога ќе види промени, може да го одложи испраќањето на барањето за изградба (одложете за периодот наведен во специјалниот параметар treeStableTimer). ВО името го поставува името на распоредот што ќе се прикаже во BuildBot-веб интерфејс. ВО Промена на филтер се поставува филтер, по поминувањето кои промени во гранката го поттикнуваат распоредот да испрати барање за изградба. ВО Имиња на градители име е наведено градител-а, што ќе го поставиме малку подоцна. Името во нашиот случај ќе биде исто како и името на проектот: вашиот Проект.
ForceScheduler многу едноставна работа. Овој тип распоред се активира со кликнување на глувчето BuildBot-веб интерфејс. Параметрите ја имаат истата суштина како кај SingleBranchScheduler.
ПС бр. 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 ги означува чекорите што треба да се следат Работник-y. Чекорите се додаваат со повикување на методот addStep
Првиот додаден чекор во овој пример е git чист -d -f -f –x, тогаш git исход. Овие дејства се вклучени во параметарот метод, што не е јасно наведено, но подразбира стандардна вредност свежо. Параметар режим='инкрементален' покажува дека датотеките се од директориумот каде што chechout, иако недостасува од складиштето, остануваат недопрени.
Вториот додаден чекор е повикување на сценариото судење со параметар Здраво на страна Работник-а од директориумот /home/habr/worker/yourProject/build со променливата на околината PATHONPATH=... Така, можете да напишете свои скрипти и да ги извршите на страна Работник- секој чекор util.ShellCommand. Овие скрипти може да се стават директно во складиштето. Потоа во chechout-е во ќе паднат /home/habr/worker/yourProject/build. Сепак, тогаш има две „но“:
- Работник мора да се креира со клуч за да не ги блокира правата за извршување по исходот-а.
- на git push-е од овие скрипти треба да го наведете имотот изменливитака што подоцна chechout-e не го изгуби правото да ја изврши скриптата Git.
5.6 градежници
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
За тоа што е Градител беше кажано . Сега ќе ви кажам подетално за тоа како да го креирате. BuilderConfig е конструктор градител. Таквите дизајнери во в['градители'] можете да наведете неколку, бидејќи ова е лист со предмети градител тип. Сега да го преработиме примерот од BuildBot, доближувајќи го до нашата задача.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Сега ќе ви кажам за параметрите BuilderConfig.
името го одредува името градител-а. Еве го именувавме вашиот Проект. Ова значи дека на Работник- ќе се создаде токму оваа патека /home/habr/worker/yourProject/build. Шедулер барајќи градител само со ова име.
работнички имиња содржи лист Работник-с. Од кои секоја мора да се додаде на в['работници'].
фабрика - специфичен се изгради, со кој е поврзан градител. Тој ќе го испрати предметот се изгради на Работник да ги завршите сите чекори вклучени во ова се изгради-а.
6. Пример за ваша сопствена конфигурација
Еве го примерот на проектната архитектура што предлагам да се имплементира преку BuildBot
.
Ќе користиме како систем за контрола на верзии svn. Самото складиште ќе се наоѓа во некој вид облак. Еве ја адресата на овој облак . Во облакот одоздола svn има корисничко име на сметката: корисникот, passwd: лозинка. Скрипти кои претставуваат чекори се изгради-а ќе биде и во гранката svn, во посебна папка buildbot/worker_linux. Овие скрипти се наоѓаат во складиштето со зачуваното својство извршна.
BuildMaster и Работник работи на истиот домаќин проект.домаќин .BuildMaster ги складира своите датотеки во папка /дома/хабр/мајстор. Работник се чува на следната патека /дом/хабр/работник. Процесна комуникација BuildMaster-а и Работник-а се врши преку порта 4000 според протоколот BuildBot-а, т.е 'pb' протокол.
Целниот проект е целосно напишан во Python. Задачата е да се следат неговите промени, да се создаде извршна датотека, да се генерира документација и да се спроведе тестирање. Во случај на неуспех, сите програмери треба да испратат порака по е-пошта во која се наведува дека има неуспешно дејство.
Веб приказ BuildBot ќе се поврземе на портата 80 за проект.домаќин. Не е неопходно да се инсталира Apatch. Како дел од библиотеката извртени веќе постои веб-сервер, BuildBot го користи.
За складирање на внатрешни информации за BuildBot ќе користиме квлит.
Потребен е домаќин за испраќање smtp.your.domain - овозможува испраќање писма од пошта projectHost@your.domain без автентикација. Исто така на домаќинот'SMTP Записникот се слуша на пошта 1025.
Во процесот се вклучени две лица: admin и корисникот. администрира BuildBot. корисникот е личноста која обврзува изврши-с.
Извршлива датотека се генерира преку pyinstaller. Документацијата се генерира преку доксиген.
За оваа архитектура го напишав ова: господар.cfg:
господар.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="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'] = "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"
}
Прво што треба BuildMaster-а и Работник-а. Потоа залепете ја оваа датотека господар.cfg в /дома/хабр/мајстор.
Следниот чекор е да ја стартувате услугата BuildMasterа
sudo buildbot start /home/habr/master
Потоа стартувајте ја услугата Работник-a
buildbot-worker start /home/habr/worker
Подготвени! Сега Buildbot ќе ги следи промените и ќе активира изврши-y во svn, изведување на чекорите на градење и тестирање на проект со горенаведената архитектура.
Подолу ќе опишам некои карактеристики на горенаведеното господар.cfg.
6.1 На пат до вашиот господар.cfg
Додека го пишував мојот господар.cfg Ќе се направат многу грешки, така што ќе биде потребно читање на датотеката за евиденција. Се чува како BuildMaster-ec апсолутна патека /home/habr/master/twistd.log, и на страна Работник-а со апсолутна патека /home/habr/worker/twistd.log. Додека ја читате грешката и ја поправате, ќе треба да ја рестартирате услугата BuildMaster-а. Еве како се прави тоа:
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 го поедноставува процесот со тоа што вели дека складиштето содржи само багажникот.
В Распоредувачи посочено Промена на филтеркој гледа Никој и асоцира гранка со неа багажникот според дадена асоцијација преку split_file_alwaystrunk. Одговарајќи на промените во багажникот, Стартува градител со име вашиот Проект.
својства тука е потребно за администраторот да добива мејлинг листи со резултати од изработка и тестирање како сопственик на процесот.
Чекор се изгради-a исходот способен целосно да ги избрише сите датотеки лоцирани во локалната верзија на складиштето Работник-А. И потоа направете го целосното svn ажурирање. Режимот е конфигуриран преку параметарот режим=целосен, метод=свеж. Параметар haltOnTailure вели дека ако svn ажурирање ќе се изврши со грешка, тогаш целиот процес на градење и тестирање треба да биде суспендиран, бидејќи понатамошните активности немаат смисла.
6.3 Писмо до вас: известувачите се овластени да се изјаснат
новинарите е услуга за испраќање известувања по е-пошта.
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="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]
Може да испраќа пораки .
Известувач за пошта користи е-пошта за испраќање известувања.
template_html го поставува шаблонот за текст за билтенот. HTML се користи за креирање на обележување. Тој е изменет од моторот (може да се спореди со django). BuildBot има збир на променливи чии вредности се заменуваат во шаблонот за време на процесот на генерирање на текстот на пораката. Овие променливи се затворени во {{ двојни кадрави загради }}. На пример, резиме го прикажува статусот на завршените операции, односно успех или неуспех. А проекти ќе излезат вашиот Проект. Значи, користејќи контролни команди во џинџа2, променливи BuildBot-a и python стринг алатки за форматирање, можете да креирате доста информативна порака.
Известувач за пошта ги содржи следните аргументи.
fromaddr – адресата од која секој ќе го добива билтенот.
испрати на заинтересираните корисници=True испраќа порака до сопственикот и корисникот кој направил изврши.
пребарување — наставка што мора да се додаде на имињата на корисниците кои го примаат билтенот. Значи admin како корисникот ќе го прими билтенот на admin@your.domain.
реледомаќин го одредува името на домаќинот на кое се отвора серверот SMTP, На smptPort го одредува бројот на портата што слуша SMTP сервер.
режим = предупредување вели дека испраќањето треба да се направи само ако има барем еден чекор се изгради-а, што заврши со неуспех на статусот или предупредување. Во случај на успех, нема потреба да испраќате билтен.
екстрапримачи содржи список на лица на кои треба да им се испрати поштата, покрај сопственикот и лицето кое го извршило изврши.
messageFormatter е објект што го одредува форматот на пораката, неговиот образец и збир на променливи достапни од џинџа2. Опции како што се wantProperties=Точно и wantSteps=Точно дефинирајте го овој сет на достапни променливи.
with['services']=[sendMessageTo All] обезбедува листа на услуги, меѓу кои ќе биде и нашата новинар.
Ние го направивме тоа! Секоја чест
Создадовме сопствена конфигурација и ја видовме функционалноста за која е способна. BuildBot. Ова, мислам, е доволно за да се разбере дали оваа алатка е потребна за да се создаде вашиот проект. Дали сте заинтересирани за него? Дали ќе ви биде корисно? Дали му е удобно да работи? Тогаш не ја пишувам оваа статија залудно.
И понатаму. Би сакал професионалната заедница да користи BuildBot, стана пошироко, прирачниците беа преведени, а имаше уште повеќе примери.
Ви благодариме на сите за вниманието. Со среќа.
Извор: www.habr.com
