(Изображение от от
Привет!
Моето име е Евгений Черкин, аз съм програмист за екип за разработка в минна компания Полиметална.
Започвайки всеки голям проект, започвате да мислите: "Какъв софтуер е по-добре да използвате, за да го поддържате?". Един ИТ проект преминава през поредица от етапи, преди да пусне следващата версия. Добре е, когато веригата от тези етапи е автоматизирана. Само по себе си се нарича автоматизираният процес на пускане на нова версия на ИТ проект Непрекъснато интегриране. buildbot се оказа добър помощник за нас, реализирайки този процес.
В тази статия реших да представя преглед на възможностите buildbot. На какво е способен този софтуер? Как да подходим към него и как да изградим нормални, ЕФЕКТИВНИ РАБОТНИ ОТНОШЕНИЯ с него? Можете да приложите нашия опит сами, като създадете работеща услуга за сглобяване и тестване на вашия проект на вашата машина.
Съдържание
Съдържание
1. Защо BuildBot?
По-рано в habr-e срещнах статии за внедряването Непрекъснато интегриране с buildbot. напр. ми се стори най-информативен. Има и друг пример - . Тези статии могат да бъдат редактирани И след това на английски. Купето е добра отправна точка. След като прочетете тези статии, със сигурност ще искате нещо за buildbot направи.
Спри се! Някой наистина ли го е използвал в своите проекти? Оказва се, че да го прилагат в своите задачи. Може да се намери употреба buildbot и в архивите на google codes.
И така, каква е логиката хората да използват Buildbot? В крайна сметка има и други инструменти: круиз контрол и Дженкинс. Ще отговоря по този начин. За повечето задачи Дженкинс и истината ще е достатъчна. на свой ред buildbot - по-адаптивни, докато задачите се решават там толкова просто, колкото в Дженкинс. Ти избираш. Но тъй като търсим инструмент за разработване на целеви проект, защо да не изберем такъв, който ще позволи, започвайки от прости стъпки, да получите система за изграждане, която има интерактивност и уникален интерфейс.
За тези, чийто целеви проект е написан на python, възниква въпросът: „Защо не изберете система за интеграция, която има ясен интерфейс по отношение на езика, използван в проекта?“ И сега е време да представим предимствата buildbot.
И така, нашият "инструментален квартет". За себе си идентифицирах четири характеристики buildbot:
- Това е рамка с отворен код под GPL лиценз.
- Това е използването на python като инструмент за конфигуриране и описание на необходимите действия.
- Това е възможност за получаване на отговор от машината, на която се извършва сглобяването
- И накрая, това са минималните изисквания за хост. Внедряването изисква python и twisted и не изисква виртуална машина и java машина.
2. Концепция, ръководена от BuildMaster
Централна част от архитектурата за разпределение на задачите е BuildMaster. Това е услуга, която:
- следи промени в дървото на източника на проекта
- изпраща команди, които трябва да бъдат изпълнени от услугата Worker за изграждане на проекта и тестването му
- уведомява потребителите за резултатите от техните действия
BuildMaster конфигуриран чрез файл master.cfg. Този файл е в корена BuildMaster. По-късно ще покажа как се създава този корен. Самият файл master.cfg съдържа python - скрипт, който използва извиквания buildbot.
Следващият по важност обект buildbot Тя си има име Работник. Тази услуга може да работи на друг хост с различна операционна система или може би на такава BuildMaster. Може да съществува и в специално подготвена виртуална среда със собствени пакети и променливи. Тези виртуални среди могат да бъдат подготвени с помощта на помощни програми на python като verticalenv, venv.
BuildMaster излъчване на команди на всички Работник-y, а той от своя страна ги изпълнява. Тоест, оказва се, че процесът на изграждане и тестване на проект може да продължи Работник-e под 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
Следващата стъпка е да настроите Tweeted и 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. Ще бъде в нашата папка. /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемСледваща стъпка. Да творим Работник. Ще бъде в нашата папка. /дом/хабр/работник.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Когато тичаш Работник, тогава по подразбиране ще създаде в /дом/хабр/работник папка с името на проекта, който е посочен в master.cfg. И в папката с името на проекта той ще създаде директория изграждане на, и тогава ще стане Поръчка. работна директория за Работник-a ще стане директория /home/habr/yourProject/build.
„Златен ключ
И сега това, за което написах предишния параграф: скрипт, който Майстор ще изисква Работник-и направено дистанционно в тази директория няма да се изпълни, защото скриптът няма права за изпълнение. За да коригирате ситуацията, имате нужда от ключ --umask=0o22, което забранява писането в тази директория, но оставя правата за стартиране. И това е всичко, което ни трябва.
BuildMaster и Работник установяват връзка помежду си. Случва се да се счупи и Работник в очакване на отговор от BuildMaster-А. Ако няма отговор, връзката се рестартира. Ключ --keepalive=60 просто е необходимо, за да се посочи времето, след което свържете рестартира.
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 работници
c['workers'] = [worker.Worker("example-worker", "pass")]Този път посочваме BuildMaster-y списък на Работник-ов. себе си Работник създадохме , което показва ти-работник-име и парола. Сега те трябва да бъдат посочени вместо това примерен работник и минавам .
5.3 източник на промяна
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
По ключ източник на промяна речник c получаваме достъп до списъка, където искате да поставите обекта, който прави заявки към хранилището с изходния код на проекта. Примерът използва Git хранилище, което се анкетира на редовни интервали.
Първият аргумент е пътят до вашето хранилище.
работен директор представлява пътя до папката, където отстрани Работник- относително към пътя /home/habr/worker/yourProject/build git ще съхранява локалната версия на хранилището.
клон съдържа специфичен клон в хранилището, който да следва.
pollInterval съдържа броя секунди, след които BuildMaster ще анкетира хранилището за промени.
Има няколко метода за проследяване на промените в хранилището на проекта.
Най-простият метод е Polling, което предполага, че BuildMaster периодично проверява сървъра с хранилището. Ако ангажират отразява промените в хранилището, тогава BuildMaster с известно забавяне ще създаде вътрешния обект промяна и го изпратете на манипулатора на събития Scheduler, който ще стартира стъпките за изграждане и тестване на проекта Работник-е. Тези стъпки ще включват актуализация хранилище. Точно на Работник-e ще създаде локално копие на хранилището. Подробностите за този процес ще бъдат разгледани по-долу в следващите два раздела. ( и ).
Още по-елегантен метод за проследяване на промените в хранилище е директното изпращане на съобщения от сървъра, който го хоства, до BuildMaster-y за промяна на изходните кодове на проекта. В този случай, веднага след като разработчикът направи ангажират, сървърът с хранилището на проекта ще изпрати съобщение BuildMaster-y. А той от своя страна ще го прихване, като създаде обект PBChangeSource. След това този обект ще бъде предаден на Scheduler, който активира стъпките за изграждане на проекта и тестването му. Важна част от този метод е работата с кука-сървърни скриптове в хранилището. В сценария кука-a, отговорен за обработка на действията, когато ангажират-e, трябва да се обадите на помощната програма изпращане на промяна и посочете мрежовия адрес BuildMaster-А. Трябва да посочите мрежовия порт, който ще слуша PBChangeSource. PBChangeSource, между другото, е част от BuildMaster-А. Този метод ще изисква правото администратор-a на сървъра, където се намира хранилището на проекта. Първо трябва да направите резервно копие на хранилището.
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-a възразявам промяна а сега всеки Sheduler въз основа на тях той изгражда заявки за стартиране на процеса на изграждане на проекта. Той обаче също така определя кога тези заявки се прехвърлят по-нататък към опашката. Предмет Строител съхранява опашка от заявки и проследява състоянието на текущото сглобяване на отделен Работник-е. Строител също съществува на BuildMaster-е и нататък Работник-е. Той изпраща със BuildMaster- и нататък Работник-и вече конкретни изграждане на - поредица от стъпки, които трябва да се следват.
Виждаме това в настоящия пример за такива планировчици Създават се 2 бр. Освен това всеки има свой собствен вид.
SingleBranchScheduler е един от най-популярните класове за планиране. Той наблюдава един клон и задейства извършена промяна в него. Когато види промените, той може да отложи изпращането на заявката за изграждане (отложи за периода, посочен в специалния параметър treeStableTimer). Най- име задава името на графика, който ще се показва в buildbot- уеб интерфейс. IN ChangeFilter задава се филтър, след преминаването на който промените в клона подканват графика да изпрати заявка за изграждане. IN builderNames името е посочено строител-a, което ще зададем малко по-късно. Името в нашия случай ще бъде същото като името на проекта: вашият проект.
ForceScheduler много просто нещо. Този тип график се задейства чрез щракване с мишката buildbot- уеб интерфейс. Параметрите са същите като в 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 показва стъпките, които трябва да се предприемат Работник-y. Стъпките се добавят чрез извикване на метод addStep
Първата добавена стъпка в този пример е git clean -d -f -f –x, тогава git проверка. Тези действия са включени в параметъра метод, което не е изрично посочено, но предполага стойност по подразбиране свеж... Параметър режим='инкрементален' казва, че файловете са от директорията, където е чекаут, докато липсват от хранилището, остават недокоснати.
Втората добавена стъпка е извикване на скрипт пробен период с параметър здравей на страната Работник-a от директория /home/habr/worker/yourProject/build с променлива на средата PATHONPATH=… По този начин можете да пишете свои собствени скриптове и да ги изпълнявате отстрани Работник- всяка стъпка util.ShellCommand. Тези скриптове могат да бъдат поставени директно в хранилището. След това при чекаут-e ще попаднат в /home/habr/worker/yourProject/build. Тогава обаче има две „но“:
- Работник трябва да се създаде с ключ така че да не блокира правата за изпълнение след това Поръчка-а.
- при git push-e от тези скриптове трябва да указва свойство изпълнимтака че по-късно чекаут-e не е загубил разрешение за изпълнение на Git скрипта.
5.6 строители
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
За това какво е Строител беше казано . Сега ще ви разкажа по-подробно как да го създадете. BuilderConfig е конструктор строител. Такива конструктори в c['строители'] може да се посочи повече от един, тъй като това е списък от обекти строител Тип. Сега нека пренапишем примера от buildbotдоближавайки го до нашия проблем.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Сега ще ви разкажа за параметрите BuilderConfig.
име уточнява името строител-а. Тук го кръстихме вашият проект. Това означава, че на Работник-e този път ще бъде създаден /home/habr/worker/yourProject/build. Sheduler търси строител само с това име.
работнически имена съдържа лист Работник-ов. Всяка от които трябва да се добави към c['работници'].
фабрика - специфични изграждане нас което е свързано строител. Ще изпрати обект изграждане на на Работник за да завършите всички стъпки, включени в това изграждане на-а.
6. Пример за собствена конфигурация
Ето примерната архитектура на проекта, чрез която предлагам да се реализира buildbot
.
Ще използваме като система за контрол на версиите svn. Самото хранилище ще бъде разположено в някакъв облак. Ето адреса на този облак . В облака под svn има потребителско име за акаунт: потребител, парола: парола. Скриптове, които са стъпки изграждане на-a също ще бъде в клона svn, в отделна папка buildbot/worker_linux. Тези скриптове са в хранилището със запазеното свойство изпълним.
BuildMaster и Работник стартирайте на същия хост project.host .BuildMaster съхранява файловете си в папка /home/habr/master. Работник той се съхранява в следния път /дом/хабр/работник. Процесна комуникация BuildMasterи и Работник-a се провежда през порт 4000 според протокола buildbot-а, т.е 'pb' протокол.
Целевият проект е изцяло написан на python. Задачата е да се проследят неговите промени, да се създаде изпълним файл, да се генерира документация и да се проведе тестване. В случай на неуспех всички разработчици трябва да изпратят съобщение до пощата, че има неуспешно действие.
уеб дисплей buildbot ще се свържем към порт 80 за project.host. Не е необходимо да инсталирате Apatch. Като част от библиотеката усукан вече има уеб сървър, buildbot го използва.
За съхраняване на вътрешна информация за buildbot ще използваме sqlite.
Необходим е хост за изпращане по пощата smtp.вашият.домейн - разрешено е изпращането на писма от пощата [имейл защитен] без удостоверяване. Също така на хостаSMTP ' Протоколът се чува на пост 1025.
В процеса участват двама души: администратор и потребител. администратор администрира buildbot. потребителят е човекът, който прави ангажират-с.
Изпълнимият файл се генерира чрез 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"
}
Първо трябва BuildMasterи и Работник-а. След това поставете този файл master.cfg в /home/habr/master.
Следващата стъпка е да стартирате услугата BuildMasterите
sudo buildbot start /home/habr/master
След това стартирайте услугата Работник-a
buildbot-worker start /home/habr/worker
Готов! Сега Buildbot ще проследи промените и ще действа ангажират-y в svnкато следвате стъпките за изграждане и тестване на проект с горната архитектура.
По-долу ще опиша някои характеристики на горното master.cfg.
6.1 По пътя към вашия master.cfg
Докато пиша моя master.cfg ще бъдат направени много грешки, така че ще е необходимо четене на лог файла. Съхранява се като BuildMaster-ec абсолютен път /home/habr/master/twistd.log, и отстрани Работник-a с абсолютен път /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 опростява процеса, като казва, че хранилището съдържа само багажник.
В Плановици посочени ChangeFilterкойто вижда None и свързва клон с него багажник според дадена асоциация чрез 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="[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 се използва за създаване на маркиране. Модифициран е от двигателя (може да се сравни с Джанго). buildbot има набор от променливи, чиито стойности се заместват в шаблона по време на формирането на текста на съобщението. Тези променливи са оградени в {{ двойни фигурни скоби }}. Например, обобщение показва състоянието на завършените операции, т.е. успех или неуспех. А проекти ще изведе вашият проект. И така, използвайки контролни команди в джинджа2, променливи buildbot-a и Python форматиращи низове, можете да създадете доста информативно съобщение.
MailNotifier съдържа следните аргументи.
от адрес - адреса, от който ще бъде изпратено писмото до всички.
sendToInterestedUsers=True изпраща съобщение до собственика и потребителя, който е направил ангажират.
за справка — суфикс, който да се добави към потребителските имена, получаващи пощенския списък. Така администратор как потребителят ще получи пощата на адреса [имейл защитен].
препредавател указва името на хоста, на който е отворен сървърът SMTP, а smptPort задава номера на порта, който слуша SMTP сървър.
режим = "предупреждение" казва, че изпращането трябва да се извършва само ако има поне една стъпка изграждане на-a, който е завършил със състояние на грешка или предупреждение. В случай на успех не се изисква изпращане по пощата.
допълнителни получатели съдържа списък на лицата, на които трябва да се изпрати пратката в допълнение към собственика и лицето, извършило изпращането ангажират.
messageFormatter е обект, който определя формата на съобщението, неговия шаблон и набор от променливи, достъпни от джинджа2. Опции като wantProperties=Вярно и wantSteps=Вярно дефинирайте този набор от налични променливи.
with['services']=[sendMessageToAll] предоставя списък от услуги, сред които ще бъдат нашите репортер.
Успяхме! Честито
Създадохме наша собствена конфигурация и видяхме функционалността, която buildbot. Мисля, че това е достатъчно, за да разберете дали този инструмент е необходим за създаване на вашия проект. Интересува ли се от теб? Ще ви бъде ли полезно? Удобен ли е за работа с него? Тогава не напразно пиша тази статия.
И по-нататък. Бих искал професионалната общност да използва buildbot, станаха по-широки, ръководствата бяха преведени и имаше още повече примери.
Благодаря на всички за вниманието. Късмет.
Източник: www.habr.com