(Bild av från
Hej!
Mitt namn är Evgeny Churkin, jag är programmerare i utvecklarteamet hos gruvföretaget Polymetal.
När man påbörjar ett stort projekt börjar man tänka: "Vilken mjukvara är bäst för att underhålla det?". Ett IT-projekt går igenom flera steg innan den nya versionen släpps. Det är bra när kedjan av dessa steg är automatiserad. Den automatiserade processen för att släppa en ny version av ett IT-projekt kallas Continuous Integration. BuildBot har visat sig vara en bra hjälpare som genomför denna process.
I den här artikeln tänkte jag ge en översikt av möjligheterna hos BuildBot. Vad kan denna mjukvara göra? Hur kan man få tillgång till den och hur bygger man en effektiv arbetsrelation med den? Vår erfarenhet kan ni tillämpa på era egna projekt, genom att skapa en bygg- och testtjänst för ert projekt på er egen maskin.
Innehåll
Innehåll
1. Varför BuildBot?
Tidigare har jag sett artiklar på habr-e om genomförande Continuous Integration med hjälp av BuildBot. Till exempel, verkar vara den mest informativa. Det finns ett annat exempel — . Dessa artiklar kan kompletteras med , och även på engelska. Tillsammans blir det en bra utgångspunkt. Efter att ha läst dessa artiklar kommer ni säkert att genast vilja göra något på BuildBot .
Vänta! Har någon överhuvudtaget använt det i sina projekt? Det visar sig att, de har använt det i sina uppgifter. Man kan hitta WSL2 istället för en HyperV-baserad backend. BuildBot även i Google-kodarkiven.
Vad är då logiken hos de som använder Buildbot? Ведь есть другие инструменты: CruiseControl och Jenkins? Jag svarar så här. För de flesta uppgifter Jenkins är det faktiskt tillräckligt. Å sin sida, BuildBot är mer anpassningsbart, samtidigt som uppgifterna löses lika enkelt som i Jenkins. Det är upp till dig att välja. Men eftersom vi letar efter ett verktyg för ett växande projekt, varför inte välja det som, med utgångspunkt i enkla steg, ger ett byggsystem med interaktivitet och ett unikt gränssnitt.
För dem vars målprojekt är skrivet på python uppstår frågan: "Varför inte välja ett integrationssystem som har ett tydligt gränssnitt utifrån det språk som används i projektet?". Här är det dags att presentera fördelarna BuildBot.
Så, vår "instrument kvartett". Jag har identifierat fyra särskilda egenskaper BuildBot:
- Detta är ett ramverk med öppen källkod under GPL-licensen
- Det handlar om att använda python som ett verktyg för konfiguration och beskrivning av de nödvändiga åtgärderna
- Det möjliggör att få ett svar från maskinen där bygget sker
- Slutligen krävs minimala krav på värden. För driftsättning krävs python och twisted, utan behov av en virtuell maskin eller java-maskin.
2. Konceptet i centrum med BuildMaster
Centralt i arkitekturen för uppdelning av uppgifter finner vi BuildMaster. Det representerar en tjänst som:
- övervakar ändringar i projektets källkodsträd
- skickar kommandon till tjänsten Worker för att bygga projektet och genomföra tester
- informerar användarna om resultatet av de genomförda åtgärderna
BuildMaster konfigureras via en fil master.cfg. Denna fil ligger i roten BuildMaster. Senare kommer jag att visa hur denna rot skapas. Filen i sig master.cfg innehåller en python -skript som använder anrop BuildBot.
Nästa viktiga objekt BuildBot kallas Arbetare. Denna tjänst kan köras på en annan värd med ett annat operativsystem, eller på den där BuildMaster. Det kan också existera i en särskilt förberedd virtuell miljö med sina egna paket och variabler. Dessa virtuella miljöer kan förberedas med hjälp av python-verktyg som vertualenv, venv.
BuildMaster översätter kommandon till varje Arbetare-en, och den utför dem. Så processen för att bygga och testa projektet kan pågå på Arbetare-n med Windows och på en annan Worker med linux.
Checkout av projektets källkod sker på varje Arbetare-en.
3. Installation
Så, låt oss börja. Som värd kommer jag att använda Ubuntu 18.04. På den kommer jag att placera en BuildMaster-a och en Arbetare-a. Men först behöver vi installera python3.7:
sudo apt-get update
sudo apt-get install python3.7
För dem som behöver python3.7.2 istället för 3.7.1 kan man göra följande:
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
Nästa steg är att installera Twisted och BuildBot, samt paket som möjliggör extra funktionalitet 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. Första stegen
Tid att skapa BuildMaster. Den kommer att finnas i vår mapp /home/habr/master.
mkdir master
buildbot create-master master # Här skapar vi faktisktNästa steg. Låt oss skapa Arbetare. Den kommer att finnas i vår mapp /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
När du startar Arbetare, kommer den som standard att skapa i /home/habr/worker mappen med namnet på projektet som anges i master.cfg. I mappen med namnet på projektet kommer den att skapa en katalog build, och vidare i den kommer den att göra checkout. Arbetskatalogen för Arbetare-a blir katalogen /home/habr/yourProject/build.
Den "gyllene" nyckeln
Och nu till det som jag skrev det föregående stycket för: skriptet som Master kommer att kräva av Arbetare-a att göra detta på distans i den här katalogen kommer inte att köras, eftersom skriptet inte har rättigheter att köra. För att åtgärda detta krävs nyckeln —umask=0o22, som begränsar skrivbehörighet i denna katalog, men lämnar körbehörighet. Och det är exakt vad vi behöver.
BuildMaster och Arbetare skapar en anslutning med varandra. Det händer att den bryts och Arbetare väntar en tid på svar från BuildMaster-a. Om inget svar kommer, återställs anslutningen. Nyckeln —keepalive=60 är just det som behövs för att ange tidsperioden efter vilken connect anslutningen omstartas.
5. Konfiguration. Steg-för-steg-recept
Konfiguration BuildMaster äggs på maskinsidan där vi körde kommandot create-master. I vårt fall — det är katalogen /home/habr/master. Konfigurationsfilen master.cfg finns fortfarande inte, men kommandot har redan skapat filen master.cmg.sample. Den måste döpas om till master.cfg.sample på master.cfg
mv master.cfg.sample master.cfgLåt oss öppna denna master.cfg. Och gå igenom dess innehåll. Efter det ska vi försöka skapa vår egen konfigurationsfil.
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 — en grundläggande konfigurationsordbok. Den måste nödvändigtvis användas i konfigurationsfilen. För bekvämlighet introduceras en alias i konfigurationskoden. «c». Namnen på c[«keyFromDist»] är fasta komponenter för interaktion med BuildMaster. För varje nyckel sätts det motsvarande objektet som värde.
5.2 arbetare
c['workers'] = [worker.Worker("example-worker", "pass")]Den här gången anger vi BuildMaster- en lista av Arbetare-er. Själva Arbetare vi skapade , genom att ange your-worker-name och password. Nu måste vi ange dem istället för example-worker och pass .
5.3 ändringskälla
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Genom nyckeln change_source av ordboken c får vi tillgång till listan där objektet som frågar källkoden för projektet ska placeras. I exemplet används en Git-repo som frågas med viss regelbundenhet.
Den första argumentet är sökvägen till ditt repository.
workdir är sökvägen till mappen där sidan Arbetare-a relaterat till sökvägen /home/habr/worker/yourProject/build kommer git att lagra den lokala versionen av repositoryt.
branch innehåller en specifik gren i repositoryt som ska övervakas.
pollInterval är antalet sekunder efter vilka BuildMaster det kommer att fråga repositoryt efter förändringar.
Det finns flera metoder för att övervaka förändringar i projektets repository.
Den enklaste metoden är Polling, vilket innebär att BuildMaster frågar regelbundet servern med arkivet. Om commit den återspeglar förändringar i arkivet, kommer BuildMaster med viss fördröjning att skapa ett internt objekt Change och skicka det till händelsebehandlaren Schemaläggare, som sedan startar stegen för att bygga och testa projektet på Arbetare-e. Bland dessa steg kommer det att anges update arkivet. Just på Arbetare-e kommer en lokal kopia av arkivet att skapas. Detaljer kring denna process kommer att avslöjas nedan i de följande två avsnitten ( och ).
En ännu mer elegant metod för att spåra förändringar i arkivet är att skicka meddelanden direkt från servern där den är hostad till BuildMaster-u om ändringar i projektets källkod. I så fall, så snart utvecklaren gör commit, kommer servern med projektets arkiv att skicka ett meddelande BuildMaster-u. Och denne kommer i sin tur att fånga det genom att skapa ett objekt PBChangeSource. Detta objekt kommer vidare att skickas till Schemaläggare, som aktiverar stegen för att bygga och testa projektet. En viktig del av denna metod är arbetet med hook-skripten på servern i arkivet. I skriptet hook-a, som ansvarar för att hantera åtgärder vid commit-e, måste man anropa verktyget sendchange och ange nätverksadressen BuildMaster-a. Det är också nödvändigt att ange nätporten som kommer att lyssna på PBChangeSource. PBChangeSource, vilket för övrigt är en del av BuildMaster-a. Denna metod kräver rättigheter för admin-a på servern där projektets arkiv är beläget. Man behöver först ta en backup av arkivet.
5.4 schemaläggare
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 – är ett element som fungerar som en trigger som startar hela kedjan av byggande och testning av projektet.
De förändringar som har registrerats change_source, omvandlades under arbetets gång BuildBot-a till ett objekt Change och nu bygger varje Sheduler på deras grund förfrågningar om att starta processen att bygga projektet. Det definierar dessutom när dessa förfrågningar ska skickas vidare i kön. Objektet Builder behåller en kö av förfrågningar och spårar statusen för den aktuella byggnaden på en separat Arbetare-e. Builder finns också på BuildMaster-e och på Arbetare-e. Det skickar också från BuildMaster-a till Arbetare-a en specifik build — serie steg som ska utföras.
Vi ser att det i det nuvarande exemplet skapas sådan schedulers i 2 stycken. Var och en har sin egen typ.
SingleBranchScheduler – en av de mest populära schematyperna. Den övervakar en gren och aktiveras av en registrerad ändring i den. När den ser ändringar kan den fördröja skickandet av byggförfrågan (fördröja under den period som anges i en särskild parameter treeStableTimer). I name anges namnet på schemat som ska visas i BuildBot-webgränssnittet. I ChangeFilter anges en filter, som vid genomgång aktiverar schemat att skicka en byggförfrågan. I builderNames anges namnet För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio.-a, som vi kommer att ange lite senare. Namnet i vårt fall kommer att vara samma som projektets namn: yourProject.
ForceScheduler är en ganska enkel sak. Denna typ av schema aktiveras med ett musklick via BuildBot-webgränssnittet. Parametrarna har samma innebörd som i SingleBranchScheduler.
P.S. #3. Kanske blir det användbart
Periodic — det är ett schema som aktiveras med en viss fast tidsperiod. Det syns ungefär så här när det anropas
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 anger tiden för denna periodicitet i sekunder.
BuildFactory skapar ett specifikt build, som sedan För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio. skickas till Arbetare. I BuildFactory anges steg som ska utföras Arbetare-u. Stegen läggs till genom att anropa metoden addStep
Det första tillagda steget i det här exemplet är git clean -d -f -f –x, sedan git checkout. Dessa åtgärder är inskrivna i parametern metod, som inte är angiven men implicerar ett standardvärde fresh. Parametern mode='incremental' indikerar att filer från katalogen där man gör chechout, under tiden förblir de som saknas i repository otouchade.
Det andra tillagda steget är att anropa skriptet trial med parametern hello på sidan Arbetare-a från katalogen /home/habr/worker/yourProject/build c miljövariabeln PATHONPATH=… Således kan du skriva egna skript och köra dem på sidan Arbetare-a via steget util.ShellCommand. Dessa skript kan placeras direkt i repository. Då vid chechout-e kommer de att hamna i /home/habr/worker/yourProject/build. Men då finns det två "men":
- Arbetare måste skapas med nyckeln för att den inte ska blockera kör rättigheter efter checkout-a.
- Vid git push-e dessa skript måste ha egenskapen exacutable, så att vid chechout-e rättigheterna för att köra skriptet Git inte går förlorade.
5.6 byggare
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Vad det är Builder berättades . Nu ska jag berätta mer om hur man skapar det. BuilderConfig är en konstruktor För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio.. Flera sådana konstruktorer kan definieras i c[‘builders’] eftersom detta är en lista av objekt För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio. av typen. Nu ska vi skriva om exemplet lite grann BuildBot, så att det mer passar vår uppgift.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Nu ska jag berätta om parametrarna BuilderConfig.
name som anger namnet För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio.-a. Här kallade vi det yourProject. Det betyder att den här vägen kommer att skapas på Arbetare-en, och den letar /home/habr/worker/yourProject/build. Sheduler just efter det namnet. För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio. workernames
innehåller en lista av -ar. Var och en av dem måste läggas till i Arbetarec[‘workers’] factory.
är en specifik , som är kopplad build. Den kommer att skicka ett objekt För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio.för att utföra alla steg som ingår i denna build till Arbetare Detta är arkitekturen av det exempelprojekt som jag föreslår att vi implementerar via build-a.
6. Exempel på egen konfiguration
Vi kommer att använda BuildBot
.
svn . Självständigt kommer repot att ligga i ett moln. Här är adressen till detta molnsvn.host/svn/yourProject/trunk , passwd: . Självständigt kommer repot att ligga i ett moln. Här är adressen till detta moln . Skripten, som utgör stegen användare-a kommer också att ligga i grenen password, i en separat mapp buildbuildbot/worker_linux . Självständigt kommer repot att ligga i ett moln. Här är adressen till detta moln. Dessa skript ligger i repositoriet med egenskapen executableoch körs på en värd project.host.
BuildMaster och Arbetare lagrar sina filer i mappen som också lagras enligt följande sökväg .BuildMaster . Samverkan mellan processerna /home/habr/master. Arbetare -a och /home/habr/worker-a sker via port 4000 över protokollet BuildMaster-a, det vill säga Arbetare‘pb’ BuildBotprotokoll. Det slutliga projektet är helt skrivet i python. Uppgiften är att följa dess ändringar, skapa en executable-fil, generera dokumentation, och genomföra tester. Vid misslyckande ska ett meddelande skickas till alla utvecklare via e-post om att det finns en misslyckad åtgärd. Webbvisningen
kopplar vi till port 80 för
. Apatch behöver inte installeras. Inkluderat i biblioteket BuildBot twisted som också lagras enligt följande sökvägfinns redan en webbserver, som används. För lagring av intern information för BuildBot För e-postutskick behövs en värd
smtp.your.domain BuildBot ska vi använda sqlite.
— där är sändning av e-post från projectHost@your.domain tillåten utan autentisering. Dessutom lyssnar protokollet ‘ smtp ‘ på port 1025.Inblandade personer under processen är två: . admin administrerar
. user är den person som genomför admin och användare-ar. BuildBotExecutable-filen genereras genom commit-er.
Den exekverbara filen genereras genom pyinstaller. Dokumentationen genereras genom doxygen.
För denna arkitektur har jag skrivit följande 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>Status för den byggda versionen: {{ summary }}</h4>
<p>Användt tjänst för byggande: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>För att se administrationsgränssnittet, följ länken: {{ buildbot_url }}</p>
<p>För att se byggresultatet, följ länken: {{ build_url }}</p>
<p>Genom att använda WinSCP kan du ansluta till servern med ip:xxx.xx.xxx.xx. Logga in med habr/password för att hämta den sammanställda executable filen från katalogen ~/worker/yourProject/build/dist.</p>
<p><b>Byggandet genomfördes via 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'] = "Byggprocessen"
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"
}
För att börja måste man BuildMaster-a, det vill säga Arbetare-a. Sedan sätt in denna fil master.cfg på /home/habr/master.
Nästa steg är att starta tjänsten BuildMaster-a
sudo buildbot start /home/habr/master
Sedan starta tjänsten Arbetare-a
buildbot-worker start /home/habr/worker
Klart! Nu Buildbot kommer att övervaka ändringar och utlösas av commit-u i . Självständigt kommer repot att ligga i ett moln. Här är adressen till detta moln, som utför bygg- och teststeg för projektet med ovanstående arkitektur.
Nedan kommer jag att beskriva några funktioner av ovanstående master.cfg.
6.1 På väg mot min master.cfg
Under skrivandet av sin master.cfg kommer det att ske många misstag, så det kommer att krävas att läsa loggfilen. Den lagras både på BuildMaster-e c med absolut sökväg /home/habr/master/twistd.log, samt på sidan Arbetare-a med absolut sökväg /home/habr/worker/twistd.log. Vid läsning av fel och dess korrigering krävs en omstart av tjänsten BuildMaster-a. Så här görs det:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Arbeta med 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)
Först, låt oss ta en titt på svn_poller. Det är samma gränssnitt som regelbundet frågar repositoryt varje minut. I detta fall svn_poller använder bara grenen trunk. Den mystiska parametern split_file=util.svn.split_file_alwaystrunk anger reglerna: hur man delar upp mappstrukturen . Självständigt kommer repot att ligga i ett moln. Här är adressen till detta moln i grenar. Den ger också relativa vägar. Å sin sida split_file_alwaystrunk förenklar processen genom att ange att det bara finns trunk.
I Schedulers anges ChangeFilter, som ser None och associerar den med grenen trunk via den angivna associationen genom split_file_alwaystrunk. Genom att reagera på ändringar i trunk, utlöser den För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio. c med namnet yourProject.
properties är här för att administratören ska få utskick om resultaten av bygg- och testprocessen som ägare av processen.
Steg build-a checkout kan utföra en fullständig borttagning av alla filer som ligger i den lokala versionen av repositoryt Arbetare-a. Och sedan utföra en fullständig svn update. Läget ställs in genom parametern mode=full, method=fresh. Parametern haltOnTailure betyder att om svn update om det skulle misslyckas, bör hela bygg- och testprocessen avbrytas, eftersom vidare åtgärder inte är meningsfulla.
6.3 Ni får ett meddelande: reporters är bemyndigad att meddela
rapporterare är en tjänst för att skicka meddelanden via e-post.
template_html=u'''
<h4>Status för den byggda versionen: {{ summary }}</h4>
<p>Användt tjänst för byggande: {{ workername }}</p>
<p>Projekt: {{ projects }}</p>
<p>För att se administrationsgränssnittet, följ länken: {{ buildbot_url }}</p>
<p>För att se byggresultatet, följ länken: {{ build_url }}</p>
<p>Genom att använda WinSCP kan du ansluta till servern med ip:xxx.xx.xxx.xx. Logga in med habr/password för att hämta den sammanställda executable filen från katalogen ~/worker/yourProject/build/dist.</p>
<p><b>Byggandet genomfördes via 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]
Den kan skicka meddelanden .
MailNotifier använder e-post för att skicka meddelanden.
template_html anger textmallen för meddelanden. För att skapa layout används html. Den är modifierad av motorn (kan jämföras med django). BuildBot har en uppsättning variabler vars värden sätts in i mallen under skapandet av meddelandets text. Dessa variabler omskrivs i {{ dubbla måsvingar }}. Till exempel, sammanfattning skriver ut status för genomförda operationer, det vill säga success eller failure. Och projekt kommer att skrivas ut. yourProject. Så, med hjälp av styrkommandon i jinja2, variabler BuildBot-a och strängformateringsverktyg i python kan man skapa ett ganska informativt meddelande.
MailNotifier innehåller följande argument.
fromaddr – adressen från vilken meddelandena kommer att skickas.
sendToInterestedUsers=True skickar meddelandet till ägaren och användaren som gjorde commit.
lookup – suffixet som ska läggas till användarnamn som får meddelandet. Så admin eftersom användaren kommer att få meddelandet på adressen admin@your.domain.
relayhost anger namnet på värden där servern är öppen Inblandade personer under processen är två:, a smptPort anger portnumret som lyssnar på Inblandade personer under processen är två: server.
mode=„warning“ anger att meddelandet endast ska skickas om åtminstone ett steg build-a avslutades med status failure eller warning. Vid success är det inte nödvändigt att skicka meddelandet.
extraRecipients innehåller listan över personer som ska få meddelandet förutom ägaren och personen som utförde commit.
messageFormatter är ett objekt som definierar meddelandets format, dess mall och uppsättningen av variabler tillgängliga från jinja2. Sådana parametrar som wantProperties=True och wantSteps=True anger denna uppsättning av tillgängliga variabler.
s[‘services’]=[sendMessageToAll] tillhandahåller en lista över tjänster, bland vilka vår reporter.
Vi gjorde det! Mina gratulationer
Vi skapade vår egen konfiguration och såg den funktionalitet som BuildBotkan erbjuda. Detta tycker jag är tillräckligt för att förstå om detta verktyg behövs för att skapa ditt projekt. Intresserar det dig? Kommer det att vara användbart för dig? Är det lätt att arbeta med? Då har jag inte skrivit denna artikel förgäves.
Och förresten. Jag skulle vilja att det professionella samhället som använder BuildBot, blev bredare, manualer översattes, och exemplen blev ännu fler.
Tack alla för er uppmärksamhet. Lycka till.
Källa: habr.com
