Příklad implementace kontinuální integrace s BuildBot

Příklad implementace kontinuální integrace s BuildBot
(Obrázek od Computerizer od Pixabay)

Ahoj!

Jmenuji se Jevgenij Čerkin, Jsem programátor ve vývojovém týmu v těžařské společnosti Polymetal.

Když začínáte jakýkoli velký projekt, začnete přemýšlet: "Jaký software je nejlepší použít k jeho údržbě?" IT projekt prochází před vydáním další verze řadou fází. Je dobré, když je řetězec těchto fází automatizován. Automatizovaný proces samotného vydání nové verze IT projektu se nazývá Kontinuální integrace. BuildBot se nám ukázal jako dobrý pomocník při implementaci tohoto procesu.

V tomto článku jsem se rozhodl poskytnout přehled možností BuildBot. Co tento software umí? Jak k němu přistupovat a jak s ním vybudovat normální EFEKTIVNÍ PRACOVNÍ VZTAH? Naše zkušenosti můžete sami uplatnit vytvořením funkční služby pro sestavení a testování vašeho projektu na vašem stroji.

Obsah

Obsah

1. Proč BuildBot?
2. Koncept vedený BuildMasterem
3. Instalace
4. První kroky

5. Konfigurace. Recept krok za krokem

5.1 BuildmasterConfig
pracovníci 5.2
5.3 change_source
5.4 plánovače

5.5 BuildFactory
5.6 stavitelů

6. Příklad vlastní konfigurace

6.1 Na cestě k vašemu master.cfg
6.2 Práce se svn
6.3 Dopis vám: reportéři jsou oprávněni prohlásit

Dokázali jsme to! Gratulujeme

1. Proč BuildBot?

Dříve na habr-e jsem narazil na články o implementaci Kontinuální integrace použití BuildBot. Například Toto Přišlo mi to nejvíce informativní. Existuje další příklad - jednodušší. Tyto články se dají okořenit příklad z manuálua tento poté v angličtině. Kupé je dobrým výchozím bodem. Po přečtení těchto článků budete pravděpodobně okamžitě chtít něco na sobě BuildBot dělat.

Stop! Použil to někdo skutečně ve svých projektech? Ukazuje se, že ano mnoho aplikovali to ve svých úkolech. Může být nalezeno příklady použití BuildBot a v archivech kódů Google.

Jaká je tedy logika lidí pomocí Buildbot? Koneckonců, existují další nástroje: CruiseControl и Jenkins. Odpovím takto. Pro většinu úkolů Jenkins a pravdy bude stačit. ve svém pořadí, BuildBot - přizpůsobivější, zatímco problémy se tam řeší stejně jednoduše jako v Jenkins. Volba je na tobě. Ale protože hledáme nástroj pro vyvíjející se cílový projekt, proč si nevybrat takový, který umožní, počínaje jednoduchými kroky, získat systém sestavení, který má interaktivitu a jedinečné rozhraní.

Pro ty, jejichž cílový projekt je napsán v pythonu, vyvstává otázka: „Proč si nezvolit integrační systém, který má jasné rozhraní z hlediska jazyka použitého v projektu?“ A nyní je čas představit výhody BuildBot.

Takže naše „instrumentální kvarteto“. Pro sebe jsem identifikoval čtyři rysy BuildBot:

  1. Jedná se o open source framework pod licencí GPL
  2. Jedná se o použití pythonu jako konfiguračního nástroje a popis požadovaných akcí
  3. Jedná se o příležitost získat odpověď od stroje, na kterém probíhá montáž
  4. Toto jsou konečně minimální požadavky na hostitele. Nasazení vyžaduje python a twisted a nevyžaduje virtuální stroj a java stroj.

2. Koncept vedený BuildMasterem

Příklad implementace kontinuální integrace s BuildBot

Ústředním prvkem architektury distribuce úkolů je BuildMaster. Jedná se o službu, která:

  • sleduje změny ve zdrojovém stromu projektu
  • posílá příkazy, které by měla služba Worker provést za účelem sestavení projektu a jeho otestování
  • oznamuje uživatelům o výsledcích provedených akcí

BuildMaster konfigurováno přes soubor master.cfg. Tento soubor je 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ší nejdůležitější objekt BuildBot To má jméno Pracovník. Tato služba může být spuštěna na jiném hostiteli s jiným OS, nebo možná na tom, kde BuildMaster. Může existovat i ve speciálně připraveném virtuálním prostředí s vlastními balíčky a proměnnými. Tato virtuální prostředí lze připravit pomocí nástrojů pythonu, jako je např virtualenv, venv.

BuildMaster vysílá příkazy všem Pracovník-y, a on je zase plní. To znamená, že se ukazuje, že proces budování a testování projektu může pokračovat Pracovník-e se systémem Windows a na jiném Workeru se systémem Linux.

Překontrolovat zdrojové kódy projektu se vyskytují na každém z nich Pracovníkeh.

3. Instalace

Tak pojďme. Jako hostitele budu používat Ubuntu 18.04. Jeden na něj položím BuildMaster-a jedna Pracovník-A. Nejprve však musíte nainstalovat python3.7:

sudo apt-get update
sudo apt-get install python3.7

Pro ty, kteří potřebují python3.7.2 místo 3.7.1, můžete udělat následující:


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

Dalším krokem je instalace Tweetoval и BuildBot, stejně jako balíčky, které vám umožňují používat 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 tvořit BuildMaster. Bude v naší složce /home/habr/master.

mkdir master
buildbot create-master master # Собственно сдесь и создаем

Další krok. Pojďme tvořit Pracovník. Bude v naší složce /domov/habr/pracovník.

mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password

Když běžíš Pracovník, pak se ve výchozím nastavení vytvoří v /domov/habr/pracovník složku s názvem projektu, který je uveden v master.cfg. A ve složce s názvem projektu vytvoří adresář stavět, a bude v tom pokračovat pokladna. Pracovní adresář pro Pracovník-a stane se z něj adresář /home/habr/yourProject/build.

„Zlatý klíč
A teď to, kvůli čemu jsem napsal předchozí odstavec: scénář, který Mistr bude požadovat od Pracovník-a provedené vzdáleně v tomto adresáři se nespustí, protože skript nemá oprávnění ke spuštění. K nápravě situace budete potřebovat klíč --umask=0o22, který zakazuje zápis do tohoto adresáře, ale zachová si spouštěcí práva. A to je vše, co potřebujeme.

BuildMaster и Pracovník navázat spojení mezi sebou. Stává se, že se odlomí a Pracovník nějakou dobu čeká na odpověď od BuildMaster-A. Pokud se neobjeví žádná odezva, připojení se restartuje. Klíč --keepalive=60 stačí uvést dobu, po které připojit restartuje.

5. Konfigurace. Recept krok za krokem

Konfigurace BuildMaster se provádí na straně stroje, kde jsme provedli příkaz vytvořit-mistr. V našem případě se jedná o adresář /home/habr/master. Konfigurační soubor master.cfg ještě neexistuje, ale samotný příkaz již soubor vytvořil master.cmg.sample. Musíte jej přejmenovat na master.cfg.ukázka в master.cfg

mv master.cfg.sample master.cfg

Pojďme otevřít tento master.cfg. A podívejme se, z čeho se skládá. A poté se pokusíme vytvořit 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 součástí konfiguračního souboru. Pro usnadnění použití je v konfiguračním kódu zaveden alias "C". Tituly klíčů в c["keyFromDist"] jsou pevné prvky pro interakci s BuildMaster. Pro každý klíč je odpovídající objekt nahrazen hodnotou.

pracovníci 5.2

c['workers'] = [worker.Worker("example-worker", "pass")]

Tentokrát naznačujeme BuildMaster-y seznam Pracovník-s. Moje maličkost Pracovník jsme vytvořili nad, což naznačuje jméno-vaše-pracovníka и heslo. Nyní je třeba je specifikovat příkladný pracovník и projít .

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))                

Podle klíče změnit_zdroj slovník c získáme přístup k seznamu, kam chceme umístit objekt, který se dotazuje úložiště se zdrojovým kódem projektu. Příklad používá úložiště Git, které je v určitých intervalech dotazováno.

První argument je cesta k vašemu úložišti.

workdir představuje cestu ke složce, kde je na straně Pracovník-vztah k cestě /home/habr/worker/yourProject/build git uloží místní verzi úložiště.

větev obsahuje konkrétní větev v úložišti, která by měla být následována.

pollInterval obsahuje počet sekund, po kterých BuildMaster požádá úložiště o změny.

Existuje několik metod, jak sledovat změny v úložišti projektu.

Nejjednodušší metoda je Dotazování, což znamená, že BuildMaster pravidelně dotazuje server s úložištěm. Li spáchat odrážely změny v úložišti BuildMaster vytvoří vnitřní objekt s určitým zpožděním Přeměna a odeslat jej do obslužné rutiny události Plánovač, která spustí kroky k sestavení a testování projektu Pracovník-E. Mezi těmito kroky budou uvedeny aktualizovat úložiště. Přesně na PracovníkTím se vytvoří místní kopie úložiště. Podrobnosti tohoto procesu budou popsány níže v následujících dvou částech. (5.4 и 5.5).

Ještě elegantnější metodou sledování změn v úložišti je posílat zprávy přímo ze serveru, na který je hostován BuildMaster- o změně zdrojových kódů projektu. V tomto případě, jakmile vývojář provede spáchat, server s úložištěm projektu odešle zprávu BuildMaster-y. A on to zase zachytí vytvořením objektu PBChangeSource. Dále bude tento objekt přenesen do Plánovač, který aktivuje kroky k sestavení projektu a jeho testování. Důležitou součástí této metody je práce s háček-serverové skripty v úložišti. Ve scénáři háček-a, odpovědný za zpracování úkonů, když spáchat-e, musíte zavolat nástroj odeslat změnu a zadejte síťovou adresu BuildMaster-A. Musíte také určit síťový port, který bude naslouchat PBChangeSource. PBChangeSource, mimochodem, je součástí BuildMaster-A. Tato metoda bude vyžadovat povolení administrátor-a na serveru, kde se nachází úložiště projektu. Nejprve budete muset vytvořit zálohu úložiště.

5.4 plánovače


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"]))

plánovače – jedná se o prvek, který funguje jako spouštěč, který spustí celý řetězec montáže a testování projektu.
Příklad implementace kontinuální integrace s BuildBot

Změny, které byly zaznamenány změnit_zdroj, transformované v procesu práce BuildBot-a namítat Přeměna a teď každý Plánovač na jejich základě sestaví požadavky na zahájení procesu sestavení projektu. Určuje však také, kdy jsou tyto požadavky přeneseny dále do fronty. Objekt Stavitel ukládá frontu požadavků a samostatně sleduje stav aktuálního sestavení Pracovník-je. Stavitel existuje na BuildMaster-e a dále Pracovník-E. Posílá s BuildMaster-a na Pracovník- a již konkrétní stavět - řada kroků, které je třeba dodržet.
Vidíme to na aktuálním příkladu např plánovače Jsou vytvořeny 2 kusy. Navíc každý má svůj vlastní typ.

SingleBranchScheduler – jedna z nejoblíbenějších lekcí v rozvrhu. Hlídá jednu větev a je spuštěna zaznamenanou změnou v ní. Když uvidí změny, může odložit odeslání požadavku na sestavení (odložit na dobu uvedenou ve speciálním parametru treeStableTimer) V název nastavuje název plánu, který se zobrazí BuildBot-webové rozhraní. V ChangeFilter je nastaven filtr, po jehož průchodu změny ve větvi vyzve rozvrh k odeslání požadavku na stavbu. V jména stavitelů je uvedeno jméno stavitel-a, kterou nastavíme o něco později. Název v našem případě bude stejný jako název projektu: vášProjekt.

ForceScheduler velmi jednoduchá věc. Tento typ rozvrhu se spouští kliknutím myši BuildBot-webové rozhraní. Parametry mají stejnou podstatu jako v SingleBranchScheduler.

PS č. 3. Možná se to bude hodit
Periodický je plán, který běží v určité časově pevné frekvenci. Hovor vypadá 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 udává čas této periodicity v sekundách.

BuildFactory vytváří konkrétní stavět, který pak stavitel posílá na Pracovník. V BuildFactory označuje kroky, které je třeba dodržet Pracovník-y. Kroky se přidávají voláním metody addStep

Prvním přidaným krokem v tomto příkladu je git clean -d -f -f -x, pak pokladna git. Tyto akce jsou zahrnuty v parametru metoda, což není jasně uvedeno, ale předpokládá výchozí hodnotu svěží. Parametr režim='přírůstkový' označuje, že soubory jsou z adresáře, kde je chechout, i když chybí v úložišti, zůstávají nedotčeny.

Druhým přidaným krokem je volání skriptu pokus s parametrem ahoj na straně Pracovník-a z adresáře /home/habr/worker/yourProject/build s proměnnou prostředí PATHONPATH=... Můžete tedy psát své vlastní skripty a spouštět je na straně Pracovník- na každém kroku util.ShellCommand. Tyto skripty lze umístit přímo do úložiště. Potom v chechout-e padnou do /home/habr/worker/yourProject/build. Existují však dvě „ale“:

  1. Pracovník musí být vytvořen pomocí klíče --umask aby neblokovala exekuční práva po pokladna-a.
  2. na git push-e z těchto skriptů musíte určit vlastnost vykonatelnýtakže později chechout-e neztratilo právo spouštět skript Git.

5.6 stavitelů


c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
                                        workernames=["example-worker"],
                                        factory=factory))

O čem je Stavitel bylo řečeno zde. Nyní vám řeknu podrobněji, jak jej vytvořit. BuilderConfig je konstruktér stavitel. Takoví návrháři v c['builders'] můžete zadat několik, protože se jedná o list objektů stavitel typ. Nyní přepišme příklad z BuildBot, čímž se přiblíží našemu úkolu.


c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
                                            workernames=["yourWorkerName"],
                                            factory=factory))

Nyní vám řeknu o parametrech BuilderConfig.

název upřesňuje jméno stavitel-A. Tady jsme to pojmenovali vášProjekt. To znamená, že na Pracovník- právě tato cesta bude vytvořena /home/habr/worker/yourProject/build. Plánovač hledat stavitel právě tímto jménem.

pracovní jména obsahuje list Pracovník-s. Každý z nich musí být přidán c['pracovníci'].

továrna - charakteristický stavět, se kterým je spojena stavitel. Odešle objekt stavět na Pracovník k dokončení všech kroků v tomto obsažených stavět-a.

6. Příklad vlastní konfigurace

Zde je příklad architektury projektu, který navrhuji implementovat prostřednictvím BuildBot
.

Použijeme jako systém pro správu verzí svn. Samotné úložiště bude umístěno v nějakém cloudu. Zde je adresa tohoto cloudu svn.host/svn/yourProject/trunk. V mraku dole svn existuje uživatelské jméno účtu: uživatel, heslo: heslo. Skripty, které představují kroky stavět-a bude také ve větvi svn, v samostatné složce buildbot/worker_linux. Tyto skripty jsou umístěny v úložišti s uloženou vlastností spustitelný.

BuildMaster и Pracovník běží na stejném hostiteli project.host .BuildMaster ukládá své soubory do složky /home/habr/master. Pracovník je uložen v následující cestě /domov/habr/pracovník. Procesní komunikace BuildMaster-a a Pracovník-a se provádí přes port 4000 podle protokolu BuildBot-a, to je 'pb' protokol.

Cílový projekt je napsán výhradně v Pythonu. Úkolem je sledovat jeho změny, vytvářet spustitelný soubor, generovat dokumentaci a provádět testování. V případě selhání musí všichni vývojáři poslat e-mailem zprávu, že došlo k neúspěšné akci.

Webové zobrazení BuildBot připojíme se k portu 80 pro project.host. Není nutné instalovat Apatch. Jako součást knihovny zkroucený již existuje webový server, BuildBot používá to.

K ukládání interních informací pro BuildBot budeme používat sqlite.

Pro odesílání pošty je vyžadován hostitel smtp.vaše.doména - umožňuje odesílání dopisů z pošty [chráněno e-mailem] bez ověření. Také na hostiteli 'smtp “ Zápis se vyslechne na poště 1025.

Na procesu se podílejí dva lidé: administrátor и uživatel. admin spravuje BuildBot. uživatel je osoba, která se zavazuje spáchat-s.

Spustitelný soubor je generován pomocí pyinstaller. Dokumentace je generována prostřednictvím doxygen.

Pro tuto architekturu jsem napsal toto: 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"
}

Nejprve potřebujete vytvořit BuildMaster-a a Pracovník-A. Poté vložte tento soubor master.cfg в /home/habr/master.

Dalším krokem je spuštění služby BuildMasteraa


sudo buildbot start /home/habr/master

Poté spusťte službu Pracovník-a


buildbot-worker start /home/habr/worker

Připraveno! Nyní Buildbot bude sledovat změny a spouštět spáchat-y dovnitř svn, provádění kroků vytváření a testování projektu s výše uvedenou architekturou.

Níže popíšu některé vlastnosti výše uvedeného master.cfg.

6.1 Na cestě k vašemu master.cfg


Při psaní mého master.cfg Dojde k mnoha chybám, takže bude nutné přečíst soubor protokolu. Ukládá se jako BuildMaster-ec absolutní cesta /home/habr/master/twistd.loga na straně Pracovník-a s absolutní cestou /home/habr/worker/twistd.log. Jakmile si přečtete chybu a opravíte ji, budete muset službu restartovat BuildMaster-A. Zde je návod, jak 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)

Pro začátek se podívejme na svn_poller. Toto je stále stejné rozhraní, pravidelně se dotazuje úložiště jednou za minutu. V tomto případě svn_poller přistupuje pouze k pobočce kufr. Tajemný parametr split_file=util.svn.split_file_alwaystrunk stanovuje pravidla: jak rozbít strukturu složek svn na větvích. Nabízí jim i relativní cesty. Ve své řadě split_file_alwaystrunk zjednodušuje proces tím, že repozitář obsahuje pouze kufr.

В Plánovače uvedeno ChangeFilterkdo vidí Nevyplněno a sdružuje s ním pobočku kufr podle dané asociace přes split_file_alwaystrunk. Reakce na změny v kufr, Spustí stavitel se jménem vášProjekt.

vlastnosti zde je potřeba, aby admin dostával seznamy adres s výsledky sestavení a testování jako vlastník procesu.

Krok stavět-a pokladna schopný kompletně smazat všechny soubory umístěné v lokální verzi úložiště Pracovník-A. A pak dělat naplno svn update. Režim se konfiguruje pomocí parametru režim=plný, metoda=čerstvé. Parametr haltOnTailure říká, že pokud svn update bude proveden s chybou, pak by měl být celý proces sestavování a testování pozastaven, protože další akce nedávají smysl.

6.3 Dopis vám: reportéři jsou oprávněni prohlásit


reportéři je služba pro zasílání upozornění e-mailem.


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]

Umí posílat zprávy různé způsoby.

MailNotifier používá e-mail k odesílání upozornění.

template_html nastaví textovou šablonu pro newsletter. HTML se používá k vytváření značek. Je upravena motorem jinja2 (lze porovnat s django). BuildBot má sadu proměnných, jejichž hodnoty jsou nahrazeny do šablony během procesu generování textu zprávy. Tyto proměnné jsou uzavřeny v {{ dvojitých složených závorkách }}. Například, shrnutí zobrazuje stav dokončených operací, tedy úspěch nebo neúspěch. A projekty bude výstup vášProjekt. Takže pomocí ovládacích příkazů v jinja2, proměnné BuildBot-a a nástroje pro formátování řetězců python, můžete vytvořit poměrně informativní zprávu.

MailNotifier obsahuje následující argumenty.

odaddr – adresa, ze které bude každý dostávat newsletter.

sendToInterestedUsers=True odešle zprávu vlastníkovi a uživateli, který provedl spáchat.

vyhledávání — přípona, která musí být přidána ke jménům uživatelů, kteří obdrží newsletter. Tak administrátor jak uživatel obdrží newsletter na adresu [chráněno e-mailem].

relayhost určuje název hostitele, na kterém je server otevřen smtp, je smptPort určuje číslo portu, který naslouchá smtp server.

mode="warning" říká, že rozesílání by mělo být provedeno pouze v případě, že existuje alespoň jeden krok stavět-a, který skončil chybou stavu nebo varováním. V případě úspěchu není potřeba zasílat newsletter.

extraPříjemci obsahuje seznam osob, kterým má být zásilka zaslána kromě vlastníka a osoby, která zásilku provedla spáchat.

messageFormatter je objekt, který určuje formát zprávy, její šablonu a sadu proměnných dostupných z jinja2. Možnosti jako např wantProperties=Pravda и wantSteps=Pravda definovat tuto sadu dostupných proměnných.

with['services']=[sendMessageToAll] poskytuje seznam služeb, mezi nimiž bude i ta naše reportér.

Dokázali jsme to! Gratulujeme

Vytvořili jsme si vlastní konfiguraci a viděli funkčnost, které je schopna. BuildBot. Myslím, že to stačí k pochopení, zda je tento nástroj potřebný k vytvoření vašeho projektu. Máte o něj zájem? Bude to pro vás užitečné? Je příjemné s ním pracovat? Pak tento článek nepíšu nadarmo.

A dál. Rád bych, aby to využila odborná veřejnost BuildBot, se rozšířil, manuály byly přeloženy a příkladů bylo ještě více.

Děkuji vám všem za pozornost. Hodně štěstí.

Zdroj: www.habr.com

Přidat komentář