(Image by from
Pozdrav!
Ime mi je Evgeny Cherkin, sem programer na ekipi razvijalcev v rudarskem podjetju Polymetal.
Ko se lotite katerega koli velikega projekta, se začnete spraševati: 'Kakšna programska oprema bi bila najboljša za njeno vzdrževanje?'. IT projekt pred izdajo nove različice opravi vrsto korakov. Dobro je, ko je veriga teh korakov avtomatizirana. Samo avtomatiziran postopek izdaje nove različice IT projekta se imenuje Neprekinjeno integracijo. BuildBot je bil dober pomočnik za izvajanje tega procesa.
V tem članku sem se odločil predstaviti pregled možnosti BuildBot. Kaj vse ta programska oprema zmore? Kako se ji približati in kako vzpostaviti NORMALNE UČINKOVITE DELOVNE ODNOS? Vaše izkušnje lahko uporabite tudi vi, tako da ustvarite na svojem računalniku delujočo storitev za sestavljanje in testiranje vašega projekta.
Vsebina
Vsebina
1. Zakaj BuildBot?
Prej sem na habr-e srečal članke o implementaciji Neprekinjeno integracijo z uporabo BuildBot. Na primer, se mi je zdela najbolj informativna. Obstaja še en primer — . Ti članki jih lahko obogatite , a , še več, v angleščini. Skupaj je to dobra izhodiščna točka. Po branju teh člankov boste zagotovo želeli takoj narediti nekaj na BuildBot .
Čakajte! Ali je kdo sploh uporabil to v svojih projektih? Očitno ja, so ga uporabili pri svojih nalogah. Lahko najdete uporabe BuildBot tudi v arhivih kode Google.
Kakšna je torej logika ljudi, ki uporabljajo Buildbot? Ведь есть другие инструменты: CruiseControl in Jenkins. Odgovorim tako. Za večino nalog Jenkins bo res dovolj. Po drugi strani pa, BuildBot je bolj prilagodljiv, pri tem pa se naloge rešujejo tako enostavno, kot v Jenkins. Izbira je vaša. Ampak ker iščemo orodje za razvojni cilj, zakaj ne izbrati tistega, ki omogoča, da na podlagi preprostih korakov pridobite sistem za sestavljanje, ki ima interaktivnost in edinstveno uporabniško vmesnik.
Za tiste, katerih ciljna rešitev je napisana v Pythonu, se pojavi vprašanje: "Zakaj ne izbrati integracijski sistem, ki ima jasen vmesnik glede na jezik, ki se uporablja v projektu?" In tu je pravi čas, da predstavimo prednosti. BuildBot.
Torej, naš "instrumentalni kvartet". Za sebe sem določil četverico značilnosti. BuildBot:
- To je ogrodje z odprto kodo pod licenco GPL.
- To pomeni uporabo Pythona kot orodja za konfiguracijo in opis zahtevnih dejanj.
- To je možnost pridobivanja odgovorov z naprave, na kateri poteka sestavljanje.
- To so končno minimalne zahteve do gostitelja. Za razporeditev potrebujemo Python in Twisted, virtualna naprava in Java naprava pa nista potrebni.
2. Koncept, ki ga vodi BuildMaster
Osrednje mesto v arhitekturi porazdelitve nalog zaseda. BuildMaster. Predstavlja storitev, ki:
- sledijo spremembam v drevesu izvornih kod projekta.
- pošilja ukaze, ki jih mora izvršiti delovna usluga za gradnjo projekta in njegovo testiranje.
- obvešča uporabnike o rezultatih izvedenih dejanj.
BuildMaster konfigurira se preko datoteke. master.cfg. Ta datoteka leži v korenu. BuildMaster. Kasneje bom pokazal, kako ta koren nastane. Sama datoteka master.cfg vsebuje Python skripto, ki uporablja klice. BuildBot.
Naslednji najpomembnejši objekt BuildBot ima naziv. Delavec. Ta storitev lahko teče na drugem gostitelju z drugo operacijsko sistemom ali pa na tistem, kjer BuildMaster. Prav tako lahko obstaja v posebej pripravljeni virtualni okolici s svojimi paketi in spremenljivkami. Ta virtualna okolja lahko pripravimo s Python orodji, kot so virtualenv, venv..
BuildMaster pošilja ukaze vsakemu Delavec-ju, ta pa jih izvrši. To pomeni, da se lahko proces gradnje in testiranja projekta odvija na Delavec-ju pod upravljanjem Windows in na drugem delavcu pod upravljanjem Linuxa.
Checkout izvornih kodov projekta poteka na vsakem Delavec-ju.
3. Namestitev
Torej, kar gremo. Kot gostitelja bom uporabljal Ubuntu 18.04. Na njem bom postavil enega BuildMaster-a in enega Delavec-a. A najprej bo potrebno namestiti Python 3.7:
sudo apt-get update
sudo apt-get install python3.7
Za tiste, ki potrebujejo Python 3.7.2 namesto 3.7.1, lahko storite naslednje:
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
Naslednji korak je namestitev Twisted. in BuildBot, in addition to packages that allow for additional functionality 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. Prvi koraki
Time to create BuildMaster. It will be in our folder /home/habr/master.
mkdir master
buildbot create-master master # This is where we actually create itNext step. We will create Delavec. It will be in our folder /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
When you run Delavec, by default it will create in /home/habr/worker the folder with the name of the project specified in master.cfg. And in the folder named after the project, it will create a directory build, and then it will perform checkout. The working directory for Delavec-a will be the directory /home/habr/yourProject/build.
The 'Golden' key
And now, for what I wrote the previous paragraph: the script that Master will require Delavec-a to perform remotely in this directory will not execute because the script does not have permission to run. To rectify this, we will need the key —umask=0o22, which imposes a restriction on writing to this directory but allows execute permissions. And that’s all we need.
BuildMaster in Delavec connect to each other. Sometimes, it drops and Delavec waits for a response from BuildMaster-a. If no response follows, the connection will be restarted. The key —keepalive=60 is exactly what we need to specify the time after which connect it restarts.
5. Konfiguracija. Korak za korakom recept
Конфигурация BuildMaster is done on the machine where we executed the command create-master. In our case, it’s the directory /home/habr/master. The configuration file master.cfg does not exist yet, however, the command has already created the file master.cmg.sample. We need to rename it to master.cfg.sample u master.cfg
mv master.cfg.sample master.cfgLet’s open this master.cfg. And analyze what it consists of. After that, we'll try to create our configuration file.
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 — osnovni rečnik konfiguracijske datoteke. Mora biti uključena u konfiguracijski fajl. Za lakše korišćenje u kodu konfiguracije uvodi se njen alias «c». Imena u c["keyFromDist"] su fiksni elementi za interakciju sa BuildMaster. Za svaki ključ kao vrednost se postavlja odgovarajući objekat.
5.2 delavci
c['workers'] = [worker.Worker("example-worker", "pass")]Ovoga puta navodimo BuildMaster- listu od Delavec-ova. Sam Delavec smo kreirali , navodeći you-worker-name in password. Sada ih treba navesti umesto example-worker in pass .
5.3 spremeni_vir
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Po ključi change_source rečnika c imamo pristup listi u koju treba staviti objekat koji upitkuje repozitorijum izvorne kodove projekta. U ovom primeru koristi se Git repozitorijum koji se upitkuje s određenim vremenskim intervalom.
Prvi argument je put do vašeg repozitorijuma.
workdir predstavlja putanju do fascikle u kojoj će sa strane Delavec-a u odnosu na put /home/habr/worker/yourProject/build git čuvati lokalnu verziju repozitorijuma.
branch sadrži određenu granu u repozitorijumu koju treba pratiti.
pollInterval sadrži broj sekundi nakon kojih BuildMaster će upitkivati repozitorijum na promene.
Postoji nekoliko metoda za praćenje promena u repozitorijumu projekta.
Najjednostavnija metoda je Polling, koja podrazumeva da BuildMaster periodično spremlja strežnik s repozitorijem. V primeru, da commit so bile spremembe odražene v repozitoriju, BuildMaster bo z nekaj zamude ustvaril notranji objekt Change in ga poslal v obdelovalec dogodkov Načrtovalec, ki bo sprožil korake za sestavljanje in testiranje projekta na Delavec-u. Med temi koraki bo navedeno update republikacije. Prav na Delavec-u se bo ustvarila lokalna kopija repozitorija. Podrobnosti tega postopka bodo razložene spodaj v naslednjih dveh razdelkih ( in ).
Še bolj eleganten način za sledenje spremembam v repozitoriju je neposredno pošiljanje sporočil s strežnika, na katerem je nameščen, BuildMaster-u o spremembah izvorne kode projekta. V tem primeru, takoj ko razvijalec naredi commit, bo strežnik z repozitorijem projekta poslal sporočilo BuildMaster-u. Ta ga bo nato ujel in ustvaril objekt PBChangeSource. Ta objekt bo nato poslan v Načrtovalec, ki bo aktiviral korake za sestavljanje in testiranje projekta. Pomemben del tega načina je delo z hook-skripti strežnika v repozitoriju. V skriptu hook-a, ki je odgovoren za obdelavo dejanj pri commit-u, je potrebno poklicati orodje sendchange in navesti omrežni naslov BuildMaster-a. Upoštevati je treba tudi omrežni port, ki ga bo poslušal PBChangeSource. PBChangeSource, ki je, mimogrede, del BuildMaster-a. Ta metoda bo potrebovala pravice admin-a na strežniku, kjer je nameščen repozitorij projekta. Predhodno je potrebno ustvariti varnostno kopijo repozitorija.
5.4 razporejevalci
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 – je element, ki predstavlja sprožilec, ki zažene celo verigo sestavljanja in testiranja projekta.
Tiste spremembe, ki so bile zabeležene change_source, so se v procesu dela BuildBot-a preoblikovale v objekt Change in zdaj vsak Scheduler na njihovi podlagi gradi zahteve za zagon postopka sestavljanja projekta. Vendar pa določa tudi, kdaj te zahteve posredovati naprej v vrsto. Objekt Builder hrani vrsto zahtev in spremlja stanje trenutnega sestavljanja na ločenem Delavec-u. Builder obstaja tudi na BuildMaster-u in na Delavec-u. On tudi pošlje s BuildMaster-a na Delavec-a že konkretno build — serijo korakov, ki jih je treba izvesti.
Vidimo, da se v trenutnem primeru ustvarjata takšni schedulers 2 kosi. Pri čemer ima vsak svoja tipa.
SingleBranchScheduler – ena iz najbolj priljubljenih razporedov. Opazuje eno vejo in se aktivira ob določenih spremembah v njej. Ko zazna spremembe, lahko odloži pošiljanje zahteve za gradnjo (odloži za čas, določen s posebnim parametr treeStableTimer). V name se določi ime razporeda, ki se bo prikazovalo v BuildBot-web vmesniku. V ChangeFilter se določi filtr, po katerem spremembe veje spodbudijo razpored, da pošlje zahtevo za gradnjo. V builderNames se navede ime builder-a, ki ga bomo določili kasneje. Ime bo v našem primeru enako imenu projekta: yourProject.
ForceScheduler je zelo preprosta stvar. Ta tip razporeda se aktivira ob kliku miške preko BuildBot-web vmesnika. Parametri imajo enako funkcijo kot v SingleBranchScheduler.
P.S. št. 3. Morda bo koristno
Periodic — to je razpored, ki se izvaja z določeno fiksno periodiko. Izgleda, da se ga pokliče približno tako
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 določa čas te periodičnosti v sekundah.
BuildFactory ustvari konkretno build, ki nato builder pošlje na Delavec. U BuildFactory se navedejo koraki, ki jih je treba izvesti Delavec-u. Koraki se dodajajo z uporabo klica metode addStep
Prvi dodani korak v tem primeru je git clean -d -f -f –x, nato git checkout. Te dejavnosti so zakodirane v parameter method, ki ni neposredno naveden, ampak implicira privzeto vrednost fresh. Parameter mode='incremental' pove, da datoteke iz imenika, v katerega se izvaja chechout, pri čemer datoteke, ki manjkajo v repozitoriju, ostanejo nedotaknjene.
Drugi dodani korak je klic skripte trial s parametrom hello na strani Delavec-a iz imenika /home/habr/worker/yourProject/build c spremenljivke okolja PATHONPATH=… Tako lahko pišete svoje skripte in jih izvajate na strani Delavec-a preko koraka util.ShellCommand. Te skripte lahko preprosto vključite v repozitorij. Tako se med chechout-e bodo pojavile v /home/habr/worker/yourProject/build. Vendar pa obstajata dve „ampak“:
- Delavec mora biti ustvarjen z ključem da ne blokira pravic za izvajanje po checkout-a.
- Pri git push-e teh skriptov je treba navesti lastnost exacutable, da ob chechout-e pravice za izvajanje skript Git ne izgubi.
5.6 graditelji
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
O tem, kaj je Builder bilo razloženo . Zdaj bom podrobneje razložil, kako ga ustvariti. BuilderConfig je konstruktor builder. Takšnih konstruktorjev v c[‘builders’] lahko določimo več, saj gre za seznam objektov builder tipa. Zdaj bomo nekoliko prepisali primer od BuildBot, ga približali naši nalogi.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Zdaj bom govoril o parametrih BuilderConfig.
name določa ime builder-a. Tukaj smo ga poimenovali yourProject. To pomeni, da bo Delavec-e ustvarjen ta pot /home/habr/worker/yourProject/build. Scheduler izvleče builder ravno po tem imenu.
workernames vsebuje seznam Delavec-ov. Vsaka od njih mora biti dodana v c[‘workers’].
factory — konkreten build, s katerim je povezan builder. Poslal bo objekt build na Delavec za izvedbo vseh korakov, ki so vključeni v to build-a.
6. Primer lastne konfiguracije
Tukaj je arhitektura vzorčnega projekta, ki jo predlagam za izvedbo preko BuildBot
.
Kot sistem za nadzor različic bomo uporabili svn. Sam repozitorij bo v nekem oblaku. Tukaj je naslov tega oblaka . V oblaku pod svn je račun username: uporabnik, passwd: password. Skripti, ki predstavljajo korake build-a bodo prav tako ležali v veji svn, v ločeni mapi buildbot/worker_linux. Ti skripti ležijo v repozitoriju s shranjeno lastnostjo executable.
BuildMaster in Delavec delujejo na enem gostitelju project.host .BuildMaster hrani svoje datoteke v mapi /home/habr/master. Delavec tudi hrani na naslednji poti /home/habr/worker. Povezava procesov BuildMaster-a in Delavec-a poteka preko 4000 porta po protokolu BuildBot-a, torej ‘pb’ protokol.
Ciljni projekt je v celoti napisan v Pythonu. Naloga je spremljanje njegovih sprememb, ustvariti izvršljivo datoteko, generirati dokumentacijo, izvesti testiranje. V primeru napake je treba vsem razvijalcem poslati sporočilo po e-pošti, da obstaja neuspešno izvedena dejanja.
Web prikaz BuildBot bomo povezali na 80 port za project.host. Apatch ni nujen. V knjižnici twisted je že prisoten spletni strežnik, BuildBot ki ga uporablja.
Za shranjevanje informacij notranje uporabe za BuildBot bomo uporabljali sqlite.
Za pošiljanje e-pošte potrebujemo gostitelja smtp.your.domain — na njem je dovoljena pošiljanje e-pošt na naslov projectHost@your.domain brez avtentikacije. Prav tako gostitelj ‘smtp ‘ protokol posluša na povezavi 1025.
V procesu sta vključeni dve osebi: admin in uporabnik. admin upravlja BuildBot. user je oseba, ki izvaja commit-e.
Izvršljiva datoteka se generira preko pyinstaller. Dokumentacija se generira putem doxygen.
Za ovu arhitekturu napisao sam sljedeće 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 можно подключиться к серверу с 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"
}
Za početak je potrebno BuildMaster-a in Delavec-a. Zatim umetnite ovu datoteku master.cfg u /home/habr/master.
Sljedeći korak je pokrenuti servis BuildMaster-а
sudo buildbot start /home/habr/master
Zatim pokrenite servis Delavec-a
buildbot-worker start /home/habr/worker
Gotovo! Sada Buildbot će pratiti promjene i aktivirati se prema commit-u u svn, izvršavajući korake izgradnje i testiranja projekta sa gore navedenom arhitekturom.
U nastavku ću opisati neke karakteristike gore navedenog master.cfg.
6.1 Na poti do svojega master.cfg
Tokom pisanja svog master.cfg bit će napravljeno mnogo grešaka, pa će biti potrebno čitati log-datoteku. Ona se čuva kako na BuildMaster-e c apsolutnom putanjom /home/habr/master/twistd.log, tako i na strani Delavec-a s apsolutnom putanjom /home/habr/worker/twistd.log. Tokom čitanja grešaka i njihovog ispravljanja bit će potrebna ponovna pokretanja servisa BuildMaster-a. Evo kako se to radi:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Delo s 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)
Za početak pogledajmo svn_poller. To je isti interfejs koji redovno pretražuje repozitorij svake minute. U ovom slučaju svn_poller obraća se samo granama trunk. Zagonetna podešavanje split_file=util.svn.split_file_alwaystrunk postavlja pravila: kako fragmentirati strukturu foldera svn na grane. On takođe nudi relativne putanje. S druge strane split_file_alwaystrunk olakšava proces, govoreći da u repozitoriju postoji samo trunk.
V Schedulers je navedeno ChangeFilter, koji vidi Noben i povezuje ga sa granom trunk prema zadanom povezivanju preko split_file_alwaystrunk. Reagujući na promjene u trunk, pokreće builder c imenom yourProject.
properties ovdje je potreban kako bi administrator primio obaveštenje o rezultatima izgradnje i testiranja kao vlasnik procesa.
Korak build-a checkout može izvršiti potpuno uklanjanje svih datoteka koje se nalaze u lokalnoj verziji repozitorija Delavec-a. A zatim izvršiti potpuno svn update. Način je podešen putem parametra mode=full, method=fresh. Parameter haltOnTailure govori da ako svn update если возникнет ошибка, то весь процесс сборки и тестирования следует приостановить, поскольку дальнейшие действия не имеют смысла.
6.3 Imate sporočilo: reporterji so pooblaščeni za izjavitev
репортеры — это сервис для отправки уведомлений на электронную почту.
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 имеет набор переменных, значения которых подставляются в шаблон в процессе формирования текста сообщения. Эти переменные вписаны в {{ двойные фигурные скобки }}. Так, например, povzetek выводит статус выполненных операций, то есть success или failure. А projects выведет yourProject. Таким образом, с помощью управляющих команд в jinja2, переменных BuildBot-а и методов форматирования строк на python можно создать вполне информативное сообщение.
MailNotifier содержит следующие аргументы.
fromaddr – адрес, с которого будут отправляться уведомления.
sendToInterestedUsers=True отправляет сообщение владельцу и пользователю, который его запросил. commit.
lookup — суффикс, который нужно добавить к именам пользователей, получающим уведомления. Таким образом, admin пользователь получит уведомление по адресу admin@your.domain.
relayhost задает имя хоста, на котором открыт сервер smtp, a smptPort задает номер порта, который прослушивается smtp server.
mode="warning" указывает, что отправка уведомлений должна происходить только при наличии хотя бы одного шага build-а, который завершился со статусом failure или warning. В случае success отправка не требуется.
extraRecipients содержит список лиц, кому следует отправить уведомления помимо владельца и лица, осуществившего commit.
messageFormatter является объектом, задающим формат сообщения, его шаблон и набор переменных, доступных из jinja2. Параметры, такие как wantProperties=True in wantSteps=True задают этот набор доступных переменных.
s[‘services’]=[sendMessageToAll] предоставляет список сервисов, среди которых будет наш репортер.
Uspelo nam je! Moje čestitke
Мы создали собственную конфигурацию и увидели функционал, на который способен BuildBot. Этого, думаю, достаточно, чтобы понять, нужен ли этот инструмент для создания вашего проекта. Он вам интересен? Будет ли он полезен? Удобно ли с ним работать? Если да, то я не зря пишу эту статью.
И еще. Хотелось бы, чтобы профессиональное сообщество, использующее BuildBot, стало шире, мануалы переводились, и примеров становилось еще больше.
Всем спасибо за внимание. Удачи.
Izvor: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
Finnish
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish