(Obrázek od from
Ahoj!
Jmenuji se Evgenij Čerkin, jsem programátor týmu vývojářů v těžební společnosti Polymetal.
Při zahájení jakéhokoliv velkého projektu začínáte přemýšlet: „Jaký software je nejlepší použít pro jeho údržbu?“. IT projekt před vydáním další verze prochází řadou fází. Je skvělé, když je řetězec těchto fází automatizován. Samotný automatizovaný proces vydání nové verze IT projektu se nazývá Continuous Integration. BuildBot a pro nás se ukázal jako dobrý pomocník, který realizuje tento proces.
V tomto článku jsem se rozhodl představit přehled možností BuildBot. Co všechno tento software dokáže? Jak se k němu přiblížit a jak s ním vybudovat normální EFEKTIVNÍ PRACOVNÍ VZTAHY? Naše zkušenosti můžete aplikovat i u sebe, vytvořením na svém stroji pracovního servisu pro sestavování a testování vašeho projektu.
Obsah
Obsah
1. Proč BuildBot?
Dříve na habr-e jsem viděl články o realizaci Continuous Integration s využitím BuildBot. Například, mi přišel nejvíce informativní. Je tu další příklad — . Tyto články lze doplnit , a navíc, v anglickém jazyce. V součtu to vytváří slušný výchozí bod. Po přečtení těchto článků se určitě okamžitě chcete pustit do něčeho na BuildBot udělat.
Zastavte! Používal někdo vůbec to ve svých projektech? Odkazuji, že ano, použili ho ve svých úlohách. Můžete ho nalézt používání BuildBot i v archivech kódu Google.
Jaká je tedy logika lidí, kteří používají Buildbot? Ведь есть другие инструменты: CruiseControl a Jenkins. Odpovím takto. Pro většinu úloh Jenkins je to skutečně dostatečné. Na druhou stranu, BuildBot je více adaptivní, přičemž úkoly tam jsou vyřešeny stejně snadno, jako v Jenkins. Je na vás si vybrat. Ale když už hledáme nástroj pro rozvíjející se cílový projekt, proč nevybrat ten, který nám umožní, na základě jednoduchých kroků, získat systém sestavení s interaktivitou a unikátním rozhraním.
Ti, jejichž projekt je napsán v Pythonu, se ptají: „Proč nevybrat integrační systém, který má jasné rozhraní podle jazyka používaného v projektu?“ A je právě čas představit výhody. BuildBot.
Takže náš „nástrojový kvartet“. Pro sebe jsem určil čtyři rysy. BuildBot:
- Jedná se o framework s otevřeným zdrojovým kódem pod licencí GPL.
- To zahrnuje použití Pythonu jako nástroje pro konfiguraci a popis potřebných akcí.
- To je možnost získat odpověď od stroje, na kterém probíhá sestavení.
- Konečně je to minimální požadavek na hostitele. Pro nasazení je vyžadován Python a twisted, a není potřeba virtuální stroj a java-stroj.
2. Koncept vedený BuildMasterem
Centrální místo v architektuře distribuce úloh zaujímá BuildMaster.Je to služba, která:
- sleduje změny v projektu zdrojového kódu.
- odesílá příkazy, které by měl služba Worker provést pro sestavení projektu a jeho testování.
- informuje uživatele o výsledcích provedených akcí.
BuildMaster. konfiguruje se prostřednictvím souboru master.cfg. Tento soubor leží v kořenovém adresáři. BuildMaster.. Později ukážu, jak se tento kořen vytváří. Samotný soubor master.cfg obsahuje Python - skript, který používá volání. BuildBot.
Dalším nejdůležitějším objektem BuildBot se nazývá Worker. Tento servis může být spuštěn na jiném hostiteli s jiným OS, nebo také na tom, kde BuildMaster.. Může také existovat ve speciálně vytvořené virtuální prostředí se svými balíčky a proměnnými. Tato virtuální prostředí mohou být připravena pomocí Python utilit jako virtualenv, venv..
BuildMaster. převádí příkazy každému Worker-ovi, a ten je pak provádí. To znamená, že proces sestavení a testování projektu může probíhat na Worker-u pod řízením Windows a na jiném Worker-u pod řízením Linuxu.
Checkout zdrojové kódy projektu probíhá na každém Worker-u.
3. Instalace
Tak pojďme na to. Jako hostitele budu používat Ubuntu 18.04. Na něm umístím jednoho BuildMaster.-a a jednoho Worker-a. Ale nejprve je potřeba nainstalovat python3.7:
sudo apt-get update
sudo apt-get install python3.7
Pro ty, kdo potřebují python3.7.2 místo 3.7.1, může to udělat následovně:
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
Dalším krokem je instalace Twisted. a BuildBot, a také balíčky, které umožňují využít další funkce 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. První kroky
Čas vytvořit BuildMaster.. Bude u nás v složce /home/habr/master.
mkdir master
buildbot create-master master # Tady vlastně vytvářímeDalší krok. Vytvoříme Worker. Bude u nás v složce /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Když spustíte Worker, vytvoří ve výchozím nastavení v /home/habr/worker složku s názvem projektu, který je uveden v master.cfg. A ve složce s názvem projektu vytvoří adresář build, do kterého bude následně umisťovat checkout. Pracovním adresářem pro Worker-a bude adresář /home/habr/yourProject/build.
„Zlatý“ klíč
A teď to, kvůli čemu jsem psal předchozí odstavec: skript, který Master vyžádá si od Worker-a provést vzdáleně v této složce, nebude vykonán, protože skript nemá oprávnění k provedení. Abychom situaci napravili, bude potřeba klíč —umask=0o22, který zakazuje zapisování do této složky, ale oprávnění ke spuštění zanechává. A to je přesně to, co potřebujeme.
BuildMaster. a Worker navazují mezi sebou spojení. Někdy dojde k přerušení a Worker nějakou dobu čeká na odpověď od BuildMaster.-a. Pokud odpověď nepřijde, spojení se restartuje. Klíč —keepalive=60 je právě potřeba k tomu, aby určil čas, po jehož uplynutí connect se restartuje.
5. Konfigurace. Krok za krokem recept
Konfigurace BuildMaster. se provádí na straně stroje, kde jsme vykonali příkaz create-master. V našem případě – to je adresář /home/habr/master. Konfigurační soubor master.cfg zatím ještě neexistuje, ale sama příkaz již vytvořil soubor master.cmg.sample. Je třeba jej přejmenovat na master.cfg.sample v master.cfg
mv master.cfg.sample master.cfgOtevřeme tento master.cfg. A rozebereme, z čeho se skládá. A poté se pokusíme vytvořit svůj vlastní konfigurační soubor.
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 — základní slovník konfiguračního souboru. Musí být vždy zahrnut v konfiguračním souboru. Pro usnadnění použití v kódu konfigurace se zavádí jeho alias "c".. Název v c[„keyFromDist“] jsou stálými prvky pro interakci s BuildMaster.. Pro každý klíč se jako hodnota používá odpovídající objekt.
5.2 workers
c['workers'] = [worker.Worker("example-worker", "pass")]Tentokrát uvádíme BuildMaster.- seznam z Worker-ů. Samotný Worker jsme vytvářeli , uvedením you-worker-name a heslo. Nyní je musíme uvést místo example-worker a 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))
Pod klíčem change_source slovníku c získáváme přístup k seznamu, do kterého je potřeba umístit objekt, který dotazuje repozitář se zdrojovým kódem projektu. V příkladu se používá Git repozitář, který je dotazován s určitou periodicitou.
První argument je cestou k vašemu repozitáři.
workdir představuje cestu k složce, kde na straně Worker-a vůči cestě /home/habr/worker/yourProject/build bude git uchovávat lokální verzi repozitáře.
branch obsahuje konkrétní větev v repozitáři, na kterou se má sledovat.
pollInterval obsahuje počet sekund, po uplynutí kterých BuildMaster. bude dotazovat repozitář na změny.
Existuje několik metod, jak sledovat změny v repozitáři projektu.
Nejjednodušší metodou je Polling, což znamená, že BuildMaster. periodicky dotazuje server s repozitářem. V případě, že commit byl odražen změny v repozitáři, pak BuildMaster. s určitou prodlevou vytvoří vnitřní objekt Change a pošle ho zpracovateli událostí Plánovač, který spustí kroky pro sestavení a testování projektu na Worker-e. Mezi tyto kroky bude zahrnuto update repuzitáře. Přesně na Worker-e se vytvoří místní kopie repozitáře. Podrobnosti tohoto procesu budou uvedeny níže v následujících dvou sekcích ( a ).
Ještě elegantnějším způsobem sledování změn v repozitáři je přímé odesílání zpráv ze serveru, na kterém je umístěn, do BuildMaster.-u o změně zdrojových kódů projektu. V tomto případě jakmile vývojář provede commit, server s repozitářem projektu pošle zprávu BuildMaster.-u. A ten ji následně zachytí vytvořením objektu PBChangeSource. Dále bude tento objekt předán do Plánovač, který aktivuje kroky pro sestavení projektu a jeho testování. Důležitá část tohoto způsobu je práce s hook-skripty serveru v repozitáři. Ve skriptu hook-a, odpovídajícího za zpracování akcí při commit-e, je třeba zavolat utilitu sendchange a uvést síťovou adresu BuildMaster.-a. Uvést je třeba i síťový port, který bude naslouchat PBChangeSource. PBChangeSource, btw, je součástí BuildMaster.-a. Tato metoda vyžaduje práva admin-a na serveru, kde je umístěn repozitář projektu. Předtím je třeba vytvořit zálohu repozitáře.
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 – to je prvek, který funguje jako spouštěč, aktivující celou řetězec sestavování a testování projektu.
Ty změny, které byly zaznamenány change_source, přeměnily se v průběhu práce BuildBot-a na objekt Change a nyní každý Scheduler na jejich základě vytváří požadavky na spuštění procesu sestavení projektu. Rozhoduje však také, kdy tyto požadavky poslat dále do fronty. Objekt Builder uchovává frontu požadavků a sleduje stav aktuálního sestavení na samostatném Worker-e. Builder existuje také na BuildMaster.-e a na Worker-e. Ten už posílá s BuildMaster.-a na Worker-a konkrétní build — sérii kroků, které je třeba provést.
Vidíme, že v aktuálním příkladu se vytvářejí 2 kusy. Přičemž každý má svůj typ. schedulers SingleBranchScheduler
SingleBranchScheduler – jedná se o jednu z nejpopulárnějších tříd harmonogramu. Sleduje jednu větev a spouští se při zaznamenané změně v ní. Když zobrazí změny, může odložit odeslání požadavku na sestavení (odložit na dobu stanovenou ve speciálním parametru treeStableTimer). V name se nastavuje název harmonogramu, který bude zobrazen v BuildBot-webovém rozhraní. V ChangeFilter se nastavuje filtr, který spouští harmonogram k odeslání požadavku na sestavení při změnách ve větvi. V builderNames se uvádí název builder-a, který určíme později. Název v našem případě bude stejný jako název projektu: yourProject.
ForceScheduler je velmi jednoduchá věc. Tento typ harmonogramu se spouští kliknutím myši prostřednictvím BuildBot-webového rozhraní. Parametry mají stejný smysl jako v SingleBranchScheduler.
P.S. č. 3. Možná se to hodí
Periodic — to je harmonogram, který se spouští s určitou pevně stanovenou periodicitou. Vypadá to asi takto
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 se stanovuje čas této periodicity v sekundách.
BuildFactory vytváří konkrétní build, který pak builder odesílá na Worker. V BuildFactory uvádějí se kroky, které je třeba provést Worker-u. Kroky se přidávají pomocí volání metody addStep
První přidaný krok v tomto příkladu — git clean -d -f -f –x, poté git checkout. Tyto kroky jsou zakódovány v parametru method, který není jasně uveden, ale předpokládá defaultní hodnotu fresh. Parametr mode='incremental' naznačuje, že soubory v adresáři, do kterého se provádí chechout, přičemž ty, které nejsou v repozitáři, zůstávají nedotčeny.
Druhý přidaný krok — je volání skriptu trial s parametrem hello na straně Worker-a z adresáře /home/habr/worker/yourProject/build c proměnné prostředí PATHONPATH=… Takto můžete psát své skripty a provádět je na straně Worker-a prostřednictvím kroku util.ShellCommand. Tyto skripty lze umístit přímo do repozitáře. Pak při chechout-e se dostanou do /home/habr/worker/yourProject/build. Nicméně pak existují dvě "ale":
- Worker musí být vytvořen s klíčem proto, aby neblokoval práva na vykonávání po checkout-a.
- Při git push-e těchto skriptů je třeba uvést vlastnost exacutable, aby pak při chechout-e práva na vykonávání skriptu Git neztratila.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
O tom, co to je Builder bylo řečeno . Teď se podrobněji podívám, jak ho vytvořit. BuilderConfig je konstruktor builder. Takových konstruktorů může být v c[‘builders’] několik, protože je to seznam objektů builder toho typu. Teď příklad mírně upravíme, BuildBot, abychom ho přiblížili naší úloze.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Teď se podívám na parametry BuilderConfig.
name určuje jméno builder-a. Zde jsme ho pojmenovali yourProject. To znamená, že na Worker-e bude vytvořena tato cesta /home/habr/worker/yourProject/build. Scheduler hledá builder právě podle tohoto jména.
workernames obsahuje seznam Worker-ů. Každý z nich by měl být přidán do c[‘workers’].
factory — konkrétní build, s nímž je asociován builder. Ten zašle objekt build na Worker k provedení všech kroků sestávajících z tohoto build-a.
6. Příklad vlastní konfigurace
Toto je architektura příkladu projektu, kterou navrhuji realizovat prostřednictvím BuildBot
.
Jako systém pro správu verzí budeme používat svn. Samotný repozitář bude umístěn v určitém cloudu. Zde je adresa tohoto cloudu . V cloudu pod svn je účet username: uživatel, passwd: heslo. Skripty, které představují kroky build-a budou také umístěny ve větvi svn, v samostatné složce buildbot/worker_linux. Tyto skripty leží v repozitáři se zachovaným atributem executable.
BuildMaster. a Worker fungují na jednom hostu project.host .BuildMaster. ukládá své soubory do složky /home/habr/master. Worker stejně tak uchovává na následující cestě /home/habr/worker. Komunikace procesů BuildMaster.-a a Worker-a probíhá prostřednictvím portu 4000 podle protokolu BuildBot-a, tedy ‘pb’ protokol.
Cílový projekt je kompletně napsán v Pythonu. Úkolem je sledovat jeho změny, vytvořit executable soubor, vygenerovat dokumentaci, provést testování. V případě selhání je třeba zaslat všem vývojářům e-mailovou zprávu s informací, že došlo k neúspěšnému provedení akce.
Webové zobrazení BuildBot připojíme na port 80 pro project.host. Apatch instalovat není nutné. V rámci knihovny twisted již obsahuje webový server, BuildBot který využívá.
Pro ukládání informací pro interní účely BuildBot budeme používat sqlite.
Pro e-mailové rozesílání je potřeba host smtp.your.domain — na něm je povoleno odesílání e-mailů z adresy projectHost@your.domain bez autentizace. Také na hostu ‘smtp ‘ protokol naslouchá na portu 1025.
Zúčastněnými osobami v procesu jsou dvě: admin a uživatel. admin spravuje BuildBot. user je osoba, která provádí commit-y.
Exacutable soubor se generuje prostřednictvím pyinstaller. Dokumentace se generuje pomocí doxygen.
Pro tuto architekturu jsem napsal následující 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>Stav postavené verze: {{ summary }}</h4>
<p>Používaná služba pro sestavení: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Pro zobrazení administračního rozhraní přejděte na odkaz: {{ buildbot_url }}</p>
<p>Pro zobrazení výsledku sestavení přejděte na odkaz: {{ build_url }}</p>
<p>Pomocí WinSCP se můžete připojit k serveru s IP: xxx.xx.xxx.xx. Přihlaste se pomocí habr/password a stáhněte sestavený spustitelný soubor z adresáře ~/worker/yourProject/build/dist.</p>
<p><b>Sestavení bylo provedeno pomocí Buildbota</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'] = "Proces sestavení"
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"
}
Nejprve je třeba BuildMaster.-a a Worker-a. Poté vložte tento soubor master.cfg v /home/habr/master.
Dalším krokem je spustit službu BuildMaster.-a
sudo buildbot start /home/habr/master
Poté spusťte službu Worker-a
buildbot-worker start /home/habr/worker
Hotovo! Nyní Buildbot bude sledovat změny a reagovat na commit-u v svn, vykonávající kroky sestavení a testování projektu s výše uvedenou architekturou.
Níže popíšu některé zvláštnosti uvedeného master.cfg.
6.1 Na cestě k vlastnímu master.cfg
Během psaní svého master.cfg dojde k mnoha chybám, proto bude třeba číst logovací soubor. Ukládá se jak na BuildMaster.-e c s absolutní cestou /home/habr/master/twistd.log, tak na straně Worker-a s absolutní cestou /home/habr/worker/twistd.log. Při čtení chyb a jejich opravách bude třeba restartovat službu BuildMaster.-a. Takhle se to dělá:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Práce se 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)
Nejprve se podívejme na svn_poller. Je to ten samý rozhraní, které pravidelně dotazuje repozitář každou minutu. V tomto případě svn_poller se dotazuje pouze na větev trunk. Tajemný parametr split_file=util.svn.split_file_alwaystrunk určuje pravidla: jak rozdělit strukturu složek svn na větve. Říká jim také relativní cesty. Na oplátku split_file_alwaystrunk zjednodušuje proces tím, že říká, že v repozitáři je pouze trunk.
V Schedulers je uvedeno ChangeFilter, který vidí None a asociuje s ním větev trunk podle zadané asociace přes split_file_alwaystrunk. Reaguje na změny v trunk, spouští builder c názvem yourProject.
>, nebo je lze definovat prostřednictvím systémové vlastnosti je zde potřebný k tomu, aby administrátor dostával zprávy o výsledcích sestavení a testování jako vlastník procesu.
Krok build-a checkout je schopen provést kompletní odstranění jakýchkoli souborů ležících v lokální verzi repozitáře Worker-a. A poté provede úplný svn update. Režim je nastaven pomocí parametru mode=full, method=fresh. Parametr haltOnTailure říká, že pokud svn update Pokud dojde k chybě, měl by být celý proces sestavení a testování pozastaven, protože další kroky nemají smysl.
6.3 Dostali jste dopis: reportéři pověřeni oznámit
reportéři – je to služba pro odesílání oznámení e-mailem.
template_html=u'''
<h4>Stav postavené verze: {{ summary }}</h4>
<p>Používaná služba pro sestavení: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Pro zobrazení administračního rozhraní přejděte na odkaz: {{ buildbot_url }}</p>
<p>Pro zobrazení výsledku sestavení přejděte na odkaz: {{ build_url }}</p>
<p>Pomocí WinSCP se můžete připojit k serveru s IP: xxx.xx.xxx.xx. Přihlaste se pomocí habr/password a stáhněte sestavený spustitelný soubor z adresáře ~/worker/yourProject/build/dist.</p>
<p><b>Sestavení bylo provedeno pomocí Buildbota</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]
Může rozesílat zprávy .
MailNotifier používá e-mail k odesílání oznámení.
template_html určuje šablonu textu pro odesílání. Pro vytvoření rozložení se používá html. Byl modifikován enginem (může být srovnán s django). BuildBot má sadu proměnných, jejichž hodnoty jsou do šablony zasazeny během procesu vytváření textu zprávy. Tyto proměnné jsou zapsány v {{ dvojitých složených závorkách }}. Například summary využívá stav vykonaných operací, tedy success nebo failure. A projekty vyvolá yourProject. Tak je možné za pomoci řídících příkazů v jinja2, proměnných BuildBot-a a prostředků formátování řetězců python vytvořit zcela informativní zprávu.
MailNotifier obsahuje následující argumenty.
fromaddr – adresa, ze které všem přichází rozesílka.
sendToInterestedUsers=True posílá zprávu vlastníkovi a uživateli, který provedl commit.
lookup – přípona, která se má přidat k uživatelským jménům, která obdrží rozesílku. Tak admin jako uživatel obdrží rozesílku na adrese admin@your.domain.
relayhost určuje název hostitele, na kterém je otevřen server smtp, a smptPort určuje číslo portu, který naslouchá smtp server.
mode=„warning“ označuje, že rozesílku je třeba provádět pouze v případě, že alespoň jeden krok build-a skončil se statusem failure nebo warning. V případě success rozesílka není nutná.
extraRecipients obsahuje seznam osob, kterým by se mělo zaslat oznámení kromě vlastníka a osoby, která commit.
messageFormatter je objektem, který určuje formát zprávy, její šablonu a sadu proměnných dostupných z jinja2. Takové parametry jako wantProperties=True a wantSteps=True určují tuto sadu dostupných proměnných.
s[‘services’]=[sendMessageToAll] poskytuje seznam služeb, mezi kterými bude náš reportér.
Dokázali jsme to! Moje gratulace
Vytvořili jsme vlastní konfiguraci a viděli funkčnost, na kterou je BuildBot. Myslím, že to stačí, abychom pochopili, zda je tento nástroj potřeba pro vytvoření vašeho projektu. Je pro vás zajímavý? Bude vám užitečný? Je s ním snadné pracovat? Pak jsem psal tento článek nadarmo.
A ještě. Rád bych, aby profesionální komunita, která používá BuildBot, byla širší, manuály byly překládány a příkladů bylo ještě více.
Všem děkuji za pozornost. Hodně štěstí.
Zdroj: habr.com
