(Obraz od z
Ahoj!
Volám sa Evgenij Čerkin, som programátor tímu vývojárov v ťažobnej spoločnosti Polymetal.
Pri začatí akéhokoľvek veľkého projektu začnete premýšľať: „Aký softvér je najlepší na jeho prevádzku?“. IT projekt pre vydaním novej verzie prechádza niekoľkými fázami. Je dobré, keď je reťazec týchto fáz automatizovaný. Automatizovaný proces vydania novej verzie IT projektu sa nazýva Continuous Integration. BuildBot pre nás sa osvedčil ako dobrý pomocník, ktorý tento proces realizuje.
V tomto článku som sa rozhodol predstaviť prehľad možností BuildBot. Na čo je tento softvér schopný? Ako sa k nemu priblížiť a ako vybudovať s ním normálne EFEKTÍVNE PRACOVNÉ VZŤAHY? Naše skúsenosti môžete využiť aj vy, vytvorením na svojom počítači pracovnej služby na zostavovanie a testovanie vášho projektu.
Obsah
Obsah
1. Prečo BuildBot?
Predtým som na habr-e stretol články o implementácii Continuous Integration s využitím BuildBot. Napríklad, mi prišiel najviac informatívny. Je tu ďalší jednoduchší príklad — . Tieto články môžu byť ozdobené , a pridaného navyše, v anglickom jazyku. Spolu to tvorí dobrý východiskový bod. Po prečítaní týchto článkov budete určite chcieť na BuildBot niečo urobiť.
Zastavte! Ale použil to niekto vo svojich projektoch? Ukazuje sa, že áno, to aplikovali vo svojich úlohách. Môžete nájsť použitia BuildBot a v archívoch kódov Google.
Aká je teda logika ľudí, ktorí používajú Buildbot? Ведь есть другие инструменты: CruiseControl a Jenkins. Odpoviem tak. Pre väčšinu úloh Jenkins to bude naozaj stačiť. Na druhej strane, BuildBot je viac adaptabilný, pričom úlohy sa tam riešia rovnako jednoducho, ako v Jenkins. Vyberáte vy. Ale keď už hľadáme nástroj pre rozvíjajúci sa cieľový projekt, prečo si nevybrať ten, ktorý umožňuje, odvodzujúc od jednoduchých krokov, získať systém zostavovania, ktorý má interaktivitu a jedinečné rozhranie.
U tých, ktorých cieľový projekt je napísaný v Pythone, sa objavuje otázka: „Prečo si nevybrať systém integrácie, ktorý má zrozumiteľné rozhranie z hľadiska jazyka použitých v projekte?“ A teraz je ten správny čas predstaviť výhody BuildBot.
Takže náš „nástrojový kvartet“. Pre seba som určil štyri charakteristiky BuildBot:
- Je to framework s otvoreným zdrojovým kódom pod licenciou GPL
- Je to použitie Pythonu ako nástroja na konfiguráciu a opis požadovaných akcií
- Je to možnosť získať odpoveď zo strany stroja, na ktorom prebieha zostavenie
- A nakoniec, minimálne požiadavky na hostiteľa. Na nasadenie je potrebný Python a Twisted, bez potreby virtuálnej mašiny a Java mašiny.
2. Koncepcia vedená BuildMasterom
Centrálne miesto v architektúre distribúcie úloh zaujíma BuildMaster. Je to služba, ktorá:
- sledovať změny v strome zdrojových kódov projektu
- posiela príkazy, ktoré by mal vykonať servis Worker na zostavenie projektu a jeho testovanie
- oznamuje používateľom výsledky vykonaných akcií
BuildMaster konfiguruje sa cez súbor master.cfg. Tento súbor sa nachádza v koreňovom adresári BuildMaster. Následne ukážem, ako sa tento koreň vytvára. Sám o sebe súbor master.cfg obsahuje Python — skript, ktorý využíva volania BuildBot.
Nasledujúci najdôležitejší objekt BuildBot má názov Worker. Táto služba môže byť spustená na inom hostiteľovi s iným OS, ale aj na tom, kde BuildMaster. Taktiež môže existovať v špeciálne pripravenej virtuálnej prostredí so svojimi balíkmi a premennými. Tieto virtuálne prostredia môžu byť pripravené pomocou Python utilít ako virtualenv, venv.
BuildMaster translíruje príkazy každému Worker-u, a ten ich následne vykonáva. To znamená, že proces zostavenia a testovania projektu môže prebiehať na Worker-e pod správou Windows a na inom Worker-e pod správou Linuxu.
Checkout zdrojových kódov projektu sa vykonáva na každom Worker-e.
3. Inštalácia
Takže, ideme na to. Ako hostiteľ použijem Ubuntu 18.04. Na ňom umiestnim jedného BuildMaster-a a jedného Worker-a. Ale najskôr je potrebné nainštalovať Python 3.7:
sudo apt-get update
sudo apt-get install python3.7
Pre tých, ktorí potrebujú Python 3.7.2 namiesto 3.7.1 je možné urobiť nasledovné:
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
Ďalším krokom je inštalácia Twisted a BuildBot, ako aj balíky umožňujúce zapojiť ďalšiu funkcionalitu 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. Prvé kroky
Čas vytvoriť BuildMaster. Bude u nás v priečinku /home/habr/master.
mkdir master
buildbot create-master master # Vlastne tu ho vytvárameDruhý krok. Vytvoríme Worker. Bude u nás v priečinku /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Keď spustíte Worker, tak predvoleně sa vytvorí v /home/habr/worker priečinok s názvom projektu, ktorý je uvedený v master.cfg. A v priečinku s názvom projektu vytvorí adresár build, a ďalej doňho bude robiť checkout. Pracovným priečinkom pre Worker-a sa stane adresár /home/habr/yourProject/build.
„Zlatý“ kľúčik
A teraz to, kvôli čomu som písal predchádzajúcu vetu: skript, ktorý Master požaduje od Worker-a vykonať vzdialene v tomto adresári, nebude vykonaný, pretože skript nemá práva na spustenie. Aby sme situáciu napravili, potrebujeme kľúčik —umask=0o22, ktorý zakazuje zápis do tohto adresára, ale ponecháva práva na spustenie. A to presne potrebujeme.
BuildMaster a Worker si vytvárajú spojenie. Niekedy sa stane, že sa preruší a Worker nejaký čas čaká na odpoveď od BuildMaster-a. Ak odpoveď nepríde, pripojenie sa reštartuje. Kľúč —keepalive=60 je presne na to, aby určil čas, po uplynutí ktorého connect sa reštartuje.
5. Konfigurácia. Krok za krokom recept
Konfigurácia BuildMaster sa vykonáva na strane stroja, kde sme zadali príkaz create-master. V našom prípade ide o adresár /home/habr/master. Konfiguračný súbor master.cfg ešte neexistuje, avšak sama príkaz už vytvoril súbor master.cmg.sample. Je potrebné premenovať ho na master.cfg.sample v master.cfg
mv master.cfg.sample master.cfgOtvoríme tento master.cfg. A rozoberieme to, z čoho sa skladá. A potom sa pokúsime vytvoriť vlastný konfiguračný súbor.
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 súboru. Musí byť nevyhnutne použitý v konfiguračnom súbore. Pre pohodlné používanie v kóde konfigurácie sa zavádza jeho pseudonym „c“. Názvy v c[«keyFromDist»] sú pevné prvky na interakciu s BuildMaster. Pre každý kľúč sa ako hodnota zaraďuje zodpovedajúci objekt.
5.2 pracovníci
c['workers'] = [worker.Worker("example-worker", "pass")]Tentoraz uvádzame BuildMaster- zoznam z Worker- ov. Sam Worker sme vytvorili , uvádzajúc your-worker-name a password. Teraz ich musíme zadať namiesto 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ľa kľúča change_source slovníka c pristupujeme k zoznamu, kam je potrebné umiestniť objekt, ktorý sa dotazuje na repo s pôvodným kódom projektu. V príklade sa používa Git repo, ktoré sa pravidelne oprašuje.
Prvý argument je cesta k vášmu repozitáru.
workdir predstavuje cestu k priečinku, kde na strane Worker-a vzhľadom na cestu /home/habr/worker/yourProject/build bude git uchovávať lokálnu verziu repozitára.
branch obsahuje konkrétnu vetvu v repozitári, po ktorej treba sledovať.
pollInterval obsahuje počet sekúnd, po uplynutí ktorých BuildMaster bude dopytovať repozitár na prítomnosť zmien.
Existuje niekoľko metód na sledovanie zmien v repozitári projektu.
Najjednoduchšia metóda je Polling, ktorý predpokladá, že BuildMaster pravidelne kontroluje server s úložiskom. Ak commit zaznamenal zmeny v úložisku, potom BuildMaster s určitým zdržaním vytvorí vnútorný objekt Change a pošle ho do spracovateľa udalostí Scheduler, ktorý spustí kroky na zostavenie a testovanie projektu na Worker-e. Medzi týmito krokmi bude uvedené update úložiska. Práve na Worker-e sa vytvorí lokálna kópia úložiska. Podrobnosti tohto procesu budú vysvetlené nižšie v nasledujúcich dvoch sekciách ( a ).
Ešte elegantnejšou metódou sledovania zmien v úložisku je priame odosielanie správ zo servera, na ktorom je umiestnené, k BuildMaster-u o zmene zdrojových kódov projektu. V tomto prípade, akonáhle vývojár urobí commit, server s úložiskom projektu pošle správu BuildMaster-u. A ten ju zase zachytí vytvorením objektu PBChangeSource. Potom bude tento objekt odoslaný do Scheduler, ktorý aktivuje kroky na zostavenie projektu a jeho testovanie. Dôležitou súčasťou tohto spôsobu je práca s hook-skriptami servera v úložisku. V skripte hook-a, ktorý zodpovedá za spracovanie akcií pri commit-e, je potrebné zavolať utilitu sendchange a uviesť sieťovú adresu BuildMaster-a. Je potrebné uviesť aj sieťový port, ktorý bude počúvať PBChangeSource. PBChangeSource, mimochodom, je súčasťou BuildMaster-a. Táto metóda si vyžaduje práva admin-a na serveri, kde je umiestnené úložisko projektu. Predtým je potrebné vytvoriť zálohu úložiska.
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 prvok, ktorý slúži ako spúšťač, aktivujúci celú reťazec zostavovania a testovania projektu.
Tieto zmeny, ktoré boli zaznamenané change_source, sa transformovali počas práce BuildBot-a na objekt Change a teraz každý Sheduler na ich základe vytvára požiadavky na spustenie procesu zostavenia projektu. Avšak určuje aj to, kedy tieto požiadavky ďalej posunúť do fronty. Objekt Builder uchováva frontu požiadaviek a sleduje stav aktuálnej zostavy na samostatnom Worker-e. Builder existuje aj na BuildMaster-e a na Worker-e. On už posiela z BuildMaster-a na Worker-a konkrétnu build — sériu krokov, ktoré sa majú vykonať.
Vidíme, že v aktuálnom príklade sa vytvárajú schedulers 2 kusy. Navyše, každý má svoj typ.
SingleBranchScheduler – jeden z najpopulárnejších typov plánovania. Sleduje jednu vetvu a aktivuje sa pri zaznamenanej zmene v nej. Keď zaznamená zmeny, môže odložiť odoslanie žiadosti na zostavenie (odložiť na obdobie, ktoré je uvedené v špeciálnom parametri treeStableTimer). V name určuje sa názov plánu, ktorý sa bude zobrazovať v BuildBot-webovom rozhraní. V ChangeFilter určuje sa filter, ktorý, keď prejde, zmeny vo vetve podnecujú plán na odoslanie žiadosti na zostavenie. V builderNames uvádza názov builder-a, ktorý určíme trochu neskôr. Názov v našom prípade bude rovnaký ako názov projektu: yourProject.
ForceScheduler je veľmi jednoduchá vec. Tento typ plánu sa aktivuje kliknutím myši cez BuildBot-webové rozhranie. Parametre majú rovnaký zmysel ako v SingleBranchScheduler.
P.S. č. 3. Možno sa zíde
Periodic — to je plán, ktorý sa aktivuje s určitou fixnou časovou periódou. Vyzerá to 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 určuje čas tejto periodicity v sekundách.
BuildFactory vytvára konkrétny build, ktorý potom builder odošle na Worker. V BuildFactory uvádzajú sa kroky, ktoré sa majú vykonať Worker-y. Kroky sa pridávajú pomocou volania metódy addStep
Prvý pridaný krok v tomto príklade je git clean -d -f -f -x, potom git checkout. Tieto akcie sú zahrnuté v parametre method, ktorý nie je priamo zobrazený, ale predpokladá hodnotu predvolenej fresh. Parameter mode='incremental' hovorí o tom, že súbory z adresára, do ktorého dochádza checkout, pričom chýbajúce v repozitári zostávajú nedotknuté.
Druhý pridaný krok je volanie skriptu trial s parametrom hello na strane Worker-a z adresára /home/habr/worker/yourProject/build s premennou prostredia PYTHONPATH=… Takto môžete písať svoje skripty a vykonávať ich na strane Worker-a cez krok util.ShellCommand. Tieto skripty môžete uložiť priamo do repozitára. Potom pri checkout-e sa dostanú do /home/habr/worker/yourProject/build. Avšak v takom prípade existujú dva „no“:
- Worker musí byť vytvorený s kľúčom aby nezablokoval práva na vykonávanie po checkout-a.
- Pri git push-e týchto skriptoch je potrebné uviesť vlastnosť executable, aby sa potom pri checkout-e práva na vykonávanie skriptu Git nestratili.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
O tom, čo to je Builder bolo povedané . Teraz podrobnejšie opíšem, ako ho vytvoriť. BuilderConfig je konštruktor builder. Takýchto konštruktorov v c[‘builders’] môže byť zadaných niekoľko, pretože ide o zoznam objektov builder tohto typu. Teraz trocha prepíšeme príklad od BuildBot, pričom ho priblížime k našej úlohe.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Teraz poviem o parametroch BuilderConfig.
name určuje názov builder-a. Tu sme ho nazvali yourProject. To znamená, že na Worker-e sa vytvorí tento konkrétny priečinok /home/habr/worker/yourProject/build. Sheduler vyhľadáva builder to práve podľa tohto názvu.
workernames obsahuje zoznam Worker-ov. Každý z nich musí byť pridaný do c[‘workers’].
factory — konkrétny build, s ktorým je asociovaný builder. Pošle objekt build na Worker na vykonanie všetkých krokov zahŕňajúcich tento build-a.
6. Príklad vlastnej konfigurácie
Tu je architektúra príkladu projektu, ktorý navrhujem realizovať cez BuildBot
.
Ako systém na kontrolu verzií použijeme svn. Samotný repozitár sa bude nachádzať v určitom cloude. Tu je adresa tohto cloudu . V cloude pod svn je účet username: user, passwd: password. Skripty, ktoré predstavujú kroky build-a, budú tiež ležať v vetve svn, v samostatnom priečinku buildbot/worker_linux. Tieto skripty sa nachádzajú v repozitári s uloženou vlastnosťou executable.
BuildMaster a Worker fungujú na jednom hosťovi project.host .BuildMaster ukladá svoje súbory v priečinku /home/habr/master. Worker rovnako ukladá na nasledujúcej ceste /home/habr/worker. Spojenie procesov BuildMaster-a a Worker-a prebieha cez port 4000 prostredníctvom protokolu BuildBot-a, teda ‘pb’ protokolu.
Cieľový projekt je celý napísaný v python-e. Úloha je sledovať jeho zmeny, vytvoriť executable súbor, vygenerovať dokumentáciu, vykonať testovanie. V prípade zlyhania je potrebné všetkým vývojárom poslať e-mail s informáciou o tom, že došlo k neúspešnému vykonaniu akcie.
Webové zobrazenie BuildBot pripojíme na port 80 pre project.host. Apache inštalovať nie je nutné. V rámci knižnice twisted už je prítomný web server, BuildBot ten sa používa.
Na uchovávanie informácií interného určenia pre BuildBot budeme používať sqlite.
Na e-mailové rozosielanie potrebujeme hosť smtp.your.domain — na ňom je povolené posielanie e-mailov z adresy projectHost@your.domain bez autentifikácie. Taktiež na hostingu ‘smtp ‘ protokol sa počúva na porte 1025.
Zúčastnení v procese sú dvaja: admin a user. admin spravuje BuildBot. user je osobou, ktorá vykonáva commit-y.
Exacutable súbor sa generuje cez pyinstaller. Dokumentácia sa generuje cez doxygen.
Pre túto architektúru som napísal nasledovné 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 zostaveného vydania: {{ summary }}</h4>
<p>Používaná služba na zostavenie: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Pre zobrazenie administračného rozhrania navštívte tento odkaz: {{ buildbot_url }}</p>
<p>Pre zobrazenie výsledku zostavenia navštívte tento odkaz: {{ build_url }}</p>
<p>Pomocou WinSCP sa môžete pripojiť k serveru s ip:xxx.xx.xxx.xx. Prihláste sa pod habr/password a získajte zostavený spustiteľný súbor z adresára ~/worker/yourProject/build/dist.</p>
<p><b>Zostavenie bolo vykonané cez 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'] = "Proces zostavenia"
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"
}
Na začiatok je potrebné BuildMaster-a a Worker-a. Potom vložiť tento súbor master.cfg v /home/habr/master.
Ďalším krokom je spustiť službu BuildMaster-а
sudo buildbot start /home/habr/master
Potom spustiť službu Worker-a
buildbot-worker start /home/habr/worker
Hotovo! Teraz Buildbot bude sledovať zmeny a aktivuje sa pri commit-u v svn, vykonávajúc kroky kompilácie a testovania projektu s predchádzajúcou architektúrou.
Nižšie uvediem niektoré špecifiká predchádzajúceho master.cfg.
6.1 Na ceste k svojmu master.cfg
Počas písania svojho master.cfg sa urobí množstvo chýb, preto bude potrebné prečítať log súbor. Ukladá sa ako na BuildMaster-e c s absolútnou cestou /home/habr/master/twistd.log, tak aj na strane Worker-a s absolútnou cestou /home/habr/worker/twistd.log. Počas čítania chýb a ich opravy bude potrebné reštartovať službu BuildMaster-a. Tu je ako sa to robí:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Práca 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)
Na začiatok sa pozrime na svn_poller. Je to ten istý rozhranie, ktoré pravidelne kontroluje repozitár raz za minútu. V tomto prípade svn_poller sa odkazuje iba na vetvu trunk. Záhadný parameter split_file=util.svn.split_file_alwaystrunk určuje pravidlá: ako rozdeliť štruktúru priečinkov svn na vetvy. Tiež im ponúka relatívne cesty. Na oplátku split_file_alwaystrunk uľahčuje proces, hovorí o tom, že v repozitári sú len trunk.
V Schedulers sa uvádza ChangeFilter, ktorý vidí None a asociuje s ním vetvu trunk podľa danej asociácie cez split_file_alwaystrunk. Reagujúc na zmeny v trunk, spúšťa builder c s menom yourProject.
properties je tu potrebný na to, aby admin dostával správy o výsledkoch kompilácie a testovania ako majiteľ procesu.
Krok build-a checkout je schopný robiť úplné odstránenie akýchkoľvek súborov ležiacich v lokálnej verzii repozitára Worker-a. A potom robiť úplný svn update. Režim je nastavený cez parameter mode=full, method=fresh. Parameter haltOnTailure hovorí o tom, že ak svn update ak proces bude vykonaný s chybou, celý proces zostavovania a testovania by sa mal pozastaviť, keďže ďalšie kroky nemajú zmysel.
6.3 Dostal/a ste e-mail: reportéri sú oprávnení oznámiť
reportéri — je služba na zasielanie notifikácií e-mailom.
template_html=u'''
<h4>Stav zostaveného vydania: {{ summary }}</h4>
<p>Používaná služba na zostavenie: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>Pre zobrazenie administračného rozhrania navštívte tento odkaz: {{ buildbot_url }}</p>
<p>Pre zobrazenie výsledku zostavenia navštívte tento odkaz: {{ build_url }}</p>
<p>Pomocou WinSCP sa môžete pripojiť k serveru s ip:xxx.xx.xxx.xx. Prihláste sa pod habr/password a získajte zostavený spustiteľný súbor z adresára ~/worker/yourProject/build/dist.</p>
<p><b>Zostavenie bolo vykonané cez 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]
Môže zasielať správy .
MailNotifier používa e-mail na zasielanie notifikácií.
template_html definuje textový šablón na zasielanie. Na vytvorenie rozloženia sa používa html. Je modifikovaný engine (môže byť porovnávaný s django). BuildBot má súbor premenných, ktorých hodnoty sú vložené do šablóny počas tvorby textu správy. Tieto premenné sú zapísané v {{ dvojitých zložených zátvorkách }}. Takže napríklad, summary vypíše stav vykonaných operácií, to znamená success alebo failure. A projects vypíše yourProject. Takže pomocou riadiacich príkazov v jinja2, premenných BuildBot-a a prostriedkov na formátovanie reťazcov python môžeme vytvoriť celkom informatívnu správu.
MailNotifier obsahuje nasledujúce argumenty.
fromaddr – adresa, z ktorej sa bude zasielať správa.
sendToInterestedUsers=True posiela správu vlastníkovi a používateľovi, ktorý urobil commit.
lookup — prípona, ktorú treba pridať k menám používateľov, ktorí dostávajú zasielanie. Tak admin ako používateľ dostane zasielanie na adresu admin@your.domain.
relayhost definuje názov hostiteľa, na ktorom je otvorený server smtp, a smptPort definuje číslo portu, ktorý počúva smtp server.
mode=«warning» hovorí, že zasielanie potrebuje byť vykonané iba v prípade, ak existuje aspoň jeden krok build-a, ktorý sa skončil so stavom failure alebo warning. V prípade success nie je potrebné zasielanie robiť.
extraRecipients obsahuje zoznam osôb, ktorým treba zaslať správy okrem vlastníka a osoby, ktorá commit.
messageFormatter je objekt určujúci formát správy, jej šablónu a súbor dostupných premenných z jinja2. Takéto parametre, ako wantProperties=True a wantSteps=True určujú tento súbor dostupných premenných.
s[‘services’]=[sendMessageToAll] poskytuje zoznam služieb, medzi ktorými bude aj náš reportér.
Podarilo sa nám to! Moje gratulácie
Vytvorili sme vlastnú konfiguráciu a videli sme funkčnosť, ktorú BuildBotje schopný. Myslím, že to stačí na to, aby ste pochopili, či je tento nástroj potrebný na vytvorenie vášho projektu. Zaujíma vás? Bude vám užitočný? Je s ním pohodlné pracovať? Potom som túto článok nepísal nadarmo.
A ešte. Rád by som, aby profesionálna komunita používajúca BuildBot, sa rozšírila, manuály sa prekladali a príkladov pribúdalo ešte viac.
Všetkým ďakujem za pozornosť. Veľa šťastia.
Zdroj: habr.com
