(Bild av från
Hälsningar!
Jag heter Evgeniy Cherkin, Jag är programmerare i ett utvecklingsteam på ett gruvbolag Polymetall.
När du startar ett stort projekt börjar du tänka: "Vilken programvara är bäst att använda för att serva den?" Ett IT-projekt går igenom ett antal steg innan nästa version släpps. Det är bra när kedjan av dessa steg är automatiserad. Den automatiserade processen att släppa en ny version av ett IT-projekt i sig kallas Kontinuerlig integration. BuildBot visade sig vara en bra assistent för oss i genomförandet av denna process.
I den här artikeln bestämde jag mig för att ge en översikt över möjligheterna BuildBot. Vad kan denna programvara göra? Hur kan man närma sig honom och hur man bygger en normal EFFEKTIV ARBETSRELATION med honom? Du kan tillämpa vår erfarenhet själv genom att skapa en fungerande tjänst för att bygga och testa ditt projekt på din maskin.
Innehåll
Innehåll
1. Varför BuildBot?
Tidigare på habr-e stötte jag på artiklar om implementering Kontinuerlig integration med BuildBot. T.ex, Jag tyckte det var mest informativt. Det finns ett annat exempel - . Dessa artiklar kan kryddas Och efter det på engelska. Coupén är en bra utgångspunkt. Efter att ha läst dessa artiklar kommer du förmodligen genast att vilja ha något på BuildBot do.
Sluta! Har någon faktiskt använt det i sina projekt? Det visar sig ja tillämpat det i sina uppgifter. Kan hittas använda BuildBot och i Googles kodarkiv.
Så vad är logiken i att människor använder Byggbot? Det finns trots allt andra verktyg: Farthållare и Jenkins. Jag kommer att svara på detta sätt. För de flesta uppgifter Jenkins och sanningen kommer att räcka. I sin tur, BuildBot - mer adaptiv, medan problem löses där lika enkelt som i Jenkins. Valet är ditt. Men eftersom vi letar efter ett verktyg för ett utvecklande målprojekt, varför inte välja ett som gör det möjligt, med enkla steg, att få ett byggsystem som har interaktivitet och ett unikt gränssnitt.
För dem vars målprojekt är skrivet i python uppstår frågan: "Varför inte välja ett integrationssystem som har ett tydligt gränssnitt vad gäller språket som används i projektet?" Och nu är det dags att presentera fördelarna BuildBot.
Så vår "instrumentalkvartett". För mig själv har jag identifierat fyra funktioner BuildBot:
- Det är ett ramverk med öppen källkod under GPL-licens
- Detta är användningen av python som ett konfigurationsverktyg och beskrivning av de nödvändiga åtgärderna
- Detta är en möjlighet att få svar från den maskin som monteringen sker på
- Dessa är slutligen minimikraven för en värd. Implementering kräver python och vriden, och kräver ingen virtuell maskin och java-maskin.
2. Koncept leds av BuildMaster
Centralt för uppgiftsfördelningsarkitekturen är BuildMaster. Det är en tjänst som:
- håller koll ändringar i projektets källträd
- skickar kommandon som ska köras av Worker-tjänsten för att bygga projektet och testa det
- meddelar användare om resultatet av vidtagna åtgärder
BuildMaster konfigureras via fil master.cfg. Den här filen finns i roten BuildMaster. Senare ska jag visa hur denna rot skapas. Själva filen master.cfg innehåller ett python-skript som använder anrop BuildBot.
Nästa viktigaste objekt BuildBot Den har ett namn Arbetare. Den här tjänsten kan lanseras på en annan värd med ett annat operativsystem, eller kanske på det där BuildMaster. Det kan också finnas i en speciellt förberedd virtuell miljö med sina egna paket och variabler. Dessa virtuella miljöer kan förberedas med hjälp av python-verktyg som virtualenv, venv.
BuildMaster sänder kommandon till alla Arbetare-y, och han i sin tur uppfyller dem. Det vill säga, det visar sig att processen att bygga och testa ett projekt kan fortsätta Arbetare-e som kör Windows och på en annan Worker som kör Linux.
Kolla upp projektkällkoder förekommer på varje Arbetare-e.
3. Installation
Låt oss gå. Jag kommer att använda Ubuntu 18.04 som värd. Jag lägger en på den BuildMaster-en och en Arbetare-a. Men först måste du installera python3.7:
sudo apt-get update
sudo apt-get install python3.7
För de som behöver python3.7.2 istället för 3.7.1 kan du göra följande:
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
Nästa steg är att installera Tweetade и BuildBot, samt paket som låter dig använda ytterligare 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
Dags att skapa BuildMaster. Det kommer att finnas i vår folder /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемNästa steg. Låt oss skapa Arbetare. Det kommer att finnas i vår folder /hem/habr/arbetare.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
När du springer Arbetare, då skapas det som standard i /hem/habr/arbetare mapp med namnet på projektet, som anges i master.cfg. Och i mappen med projektets namn kommer det att skapa en katalog SLUTRESULTAT, och kommer att fortsätta att göra det kassan. Arbetskatalog för Arbetare-och det kommer att bli en katalog /home/habr/dittProjekt/bygga.
"Gyllene nyckel
Och nu vad jag skrev föregående stycke för: ett manus som Mästare kommer att kräva från Arbetare-och som görs på distans i den här katalogen kommer inte att köras eftersom skriptet inte har rättigheterna att köras. För att rätta till situationen behöver du en nyckel --umask=0o22, som förbjuder skrivning till den här katalogen, men kommer att behålla starträttigheterna. Och det är allt vi behöver.
BuildMaster и Arbetare upprätta en förbindelse med varandra. Det händer att det går av och Arbetare väntar ett tag på svar från BuildMaster-A. Om det inte finns något svar startas anslutningen om. Nyckel --keepalive=60 behövde bara ange tiden efter vilken ansluta startar om.
5. Konfiguration. Steg för steg recept
konfiguration BuildMaster utförs på sidan av maskinen där vi utförde kommandot skapa-mästare. I vårt fall är detta en katalog /home/habr/master. Konfigurationsfil master.cfg finns inte ännu, men själva kommandot har redan skapat filen master.cmg.sample. Du måste byta namn på den till master.cfg.sample в master.cfg
mv master.cfg.sample master.cfgLåt oss öppna den här master.cfg. Och låt oss titta på vad den består av. Och efter det, låt oss 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 — grundläggande ordbok för konfigurationsfilen. Det måste finnas med i konfigurationsfilen. För att underlätta användningen introduceras ett alias i konfigurationskoden "c". Titlar в c["keyFromDist"] är fasta element för interaktion med BuildMaster. För varje nyckel ersätts motsvarande objekt som ett värde.
5.2 arbetare
c['workers'] = [worker.Worker("example-worker", "pass")]Den här gången anger vi BuildMaster-y lista över Arbetare-s. Jag själv Arbetare vi skapade , indikerar du-arbetarnamn и Lösenord. Nu behöver de specificeras istället exempel-arbetare и passera .
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))
Med nyckel ändra_källa ordbok c får vi tillgång till listan där vi vill lägga ett objekt som pollar förvaret med projektets källkod. Exemplet använder ett Git-förråd som pollas med vissa intervall.
Det första argumentet är vägen till ditt arkiv.
arbetsdir representerar sökvägen till mappen där på sidan Arbetare-en släkting till stigen /hem/habr/arbetare/dittprojekt/bygga git kommer att lagra den lokala versionen av förvaret.
gren innehåller en specifik gren i förvaret som bör följas.
pollInterval innehåller antalet sekunder efter vilket BuildMaster kommer att undersöka arkivet för ändringar.
Det finns flera metoder för att spåra ändringar i ett projekts arkiv.
Den enklaste metoden är Polling, vilket innebär det BuildMaster frågar regelbundet servern med arkivet. Om förbinda återspeglade förändringarna i förvaret, alltså BuildMaster kommer att skapa ett internt objekt med viss fördröjning byta och skicka den till händelsehanteraren Scheduler, som kommer att lansera stegen att bygga och testa projektet på Arbetare-e. Bland dessa steg kommer att anges uppdatering förvaret. Exakt på ArbetareDetta kommer att skapa en lokal kopia av förvaret. Detaljerna för denna process kommer att behandlas nedan i de kommande två avsnitten. ( и ).
En ännu mer elegant metod för att spåra ändringar i ett arkiv är att skicka meddelanden direkt från servern som det är värd för BuildMaster- om att ändra projektets källkoder. I det här fallet, så snart utvecklaren gör förbinda, kommer servern med projektförrådet att skicka ett meddelande BuildMaster-y. Och han kommer i sin tur att fånga upp det genom att skapa ett objekt PBChangeSource. Därefter kommer detta objekt att överföras till Scheduler, som aktiverar stegen för att bygga projektet och testa det. En viktig del av denna metod är att arbeta med krok-serverskript i förvaret. I manuset krok-a, ansvarig för att behandla åtgärder när förbinda-e, du måste ringa verktyget skicka ändring och ange nätverksadressen BuildMaster-A. Du måste också ange nätverksporten som ska lyssna PBChangeSource. PBChangeSource, förresten, är en del BuildMaster-A. Denna metod kräver tillstånd administration-a på servern där projektförrådet finns. Du måste först göra en säkerhetskopia av förvaret.
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"]))
schemaläggare – detta är ett element som fungerar som en trigger som startar hela kedjan av montering och testning av projektet.
Dessa ändringar som registrerades ändra_källa, förvandlas under arbetets gång BuildBot-a att invända byta och nu varje Sheduler baserat på dem skapar den förfrågningar för att starta projektbyggeprocessen. Det avgör dock också när dessa förfrågningar överförs vidare till kön. Ett objekt Builder lagrar en kö av förfrågningar och spårar tillståndet för den aktuella sammansättningen på en separat Arbetare-och. Builder finns på BuildMaster-e och vidare Arbetare-e. Han skickar med BuildMaster-a på Arbetare-och redan specifik SLUTRESULTAT - en rad steg som måste följas.
Vi ser att i det aktuella exemplet sådana schemaläggare 2 stycken skapas. Dessutom har var och en sin egen typ.
SingleBranchScheduler – en av de mest populära klasserna på schemat. Den bevakar en gren och utlöses av en registrerad förändring i den. När han ser ändringar kan han fördröja sändningen av byggbegäran (skjut upp för den period som anges i den speciella parametern treeStableTimer). I namn anger namnet på schemat som kommer att visas i BuildBot-webbgränssnitt. I Byt filter ett filter sätts, efter att ha godkänt vilka ändringar i grenen som uppmanar schemat att skicka en förfrågan om konstruktion. I byggarnamn namn anges byggare-a, som vi sätter lite senare. Namnet i vårt fall kommer att vara detsamma som projektnamnet: ditt projekt.
ForceScheduler en väldigt enkel sak. Denna typ av schema utlöses av ett musklick igenom BuildBot-webbgränssnitt. Parametrarna har samma essens som i SingleBranchScheduler.
PS nr 3. Kanske kommer det väl till pass
Periodisk är ett schema som körs med en viss tidsbestämd frekvens. Samtalet ser ut ungefär så här
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 en specifik SLUTRESULTAT, vilken då byggare skickar till Arbetare. I BuildFactory anger de steg som ska följas Arbetare-y. Steg läggs till genom att anropa metoden addStep
Det första tillagda steget i detta exempel är git clean -d -f -f –xdå git kassan. Dessa åtgärder ingår i parametern metod, vilket inte är tydligt men antyder ett standardvärde färsk. Parameter mode='inkrementell' indikerar att filerna kommer från katalogen där chechout, medan den saknas i förvaret, förblir orörd.
Det andra tillagda steget är att anropa skriptet rättegång med parameter hallå på sidan Arbetare-a från katalogen /hem/habr/arbetare/dittprojekt/bygga med miljövariabeln PATHONPATH=... Du kan alltså skriva dina egna skript och köra dem vid sidan av Arbetare-a varje steg util.ShellCommand. Dessa skript kan placeras direkt i arkivet. Sedan kl chechout-e kommer de att falla i /hem/habr/arbetare/dittprojekt/bygga. Men då finns det två "men":
- Arbetare måste skapas med en nyckel så att den inte blockerar exekveringsrättigheterna efter kassan-a.
- vid git push-E av dessa skript behöver du för att ange egenskapen exekutivtså det senare chechout-e förlorade inte rätten att köra Git-skriptet.
5.6 byggare
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Om vad det är Builder fick veta . Nu kommer jag att berätta mer detaljerat om hur du skapar det. BuilderConfig är en konstruktör byggare. Sådana designers i c['byggare'] du kan ange flera, eftersom detta är ett ark med objekt byggare typ. Låt oss nu skriva om exemplet från BuildBot, vilket för det närmare vår uppgift.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Nu ska jag berätta om parametrarna BuilderConfig.
namn anger namnet byggare-a. Här döpte vi den ditt projekt. Detta betyder att på Arbetare– just den här vägen kommer att skapas /hem/habr/arbetare/dittprojekt/bygga. Sheduler letar efter byggare bara med detta namn.
arbetarnamn innehåller ark Arbetare-s. Var och en måste läggas till c['arbetare'].
fabrik - specifik SLUTRESULTAT, som den är förknippad med byggare. Han kommer att skicka föremålet SLUTRESULTAT på Arbetare för att slutföra alla steg som ingår i detta SLUTRESULTAT-a.
6. Exempel på din egen konfiguration
Här är exempel på projektarkitekturen som jag föreslår att implementera via BuildBot
.
Vi kommer att använda som ett versionskontrollsystem svn. Själva förvaret kommer att ligga i något slags moln. Här är adressen till detta moln . I molnet under svn det finns ett kontoanvändarnamn: användare, lösenord: Lösenord. Skript som representerar steg SLUTRESULTAT-a kommer också att finnas i filialen svn, i en separat mapp buildbot/worker_linux. Dessa skript finns i arkivet med den sparade egenskapen exekverbar.
BuildMaster и Arbetare kör på samma värd project.host .BuildMaster lagrar sina filer i en mapp /home/habr/master. Arbetare den lagras i följande sökväg /hem/habr/arbetare. Processkommunikation BuildMaster-a och Arbetare-a utförs genom port 4000 enligt protokollet BuildBot-a, alltså 'pb' protokoll.
Målprojektet är helt skrivet i Python. Uppgiften är att spåra dess ändringar, skapa en körbar fil, generera dokumentation och genomföra tester. I händelse av misslyckande måste alla utvecklare skicka ett meddelande via e-post om att det finns en misslyckad åtgärd.
Webbvisning BuildBot vi kommer att ansluta till port 80 för project.host. Det är inte nödvändigt att installera Apatch. Som en del av biblioteket tvinnade det finns redan en webbserver, BuildBot använder det.
För att lagra intern information för BuildBot vi kommer använda sqlite.
En värd krävs för utskick smtp.din.domän - det tillåter att skicka brev från post [e-postskyddad] utan autentisering. Också på värden 'smtp ' Protokollet hörs på post 1025.
Det är två personer involverade i processen: administration и användare. admin administrerar BuildBot. användare är den person som begår förbinda-s.
Exekverbar fil genereras via pyinstaller. Dokumentation genereras via syre.
För den här arkitekturen skrev jag detta: 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"
}
För att komma igång behöver du BuildMaster-a och Arbetare-a. Klistra sedan in den här filen master.cfg в /home/habr/master.
Nästa steg är att starta tjänsten BuildMasters
sudo buildbot start /home/habr/master
Starta sedan tjänsten Arbetare-a
buildbot-worker start /home/habr/worker
Redo! Nu Byggbot kommer att spåra ändringar och utlösa förbinda-y in svn, utföra stegen att bygga och testa ett projekt med ovanstående arkitektur.
Nedan kommer jag att beskriva några funktioner i ovanstående master.cfg.
6.1 På väg till din master.cfg
Medan jag skriver min master.cfg Många fel kommer att göras, så att läsa loggfilen kommer att krävas. Den lagras som BuildMaster-ec absolut väg /home/habr/master/twistd.log, och på sidan Arbetare-en med absolut väg /home/habr/worker/twistd.log. När du läser felet och åtgärdar det måste du starta om tjänsten BuildMaster-a. Så här går det till:
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)
Låt oss först ta en titt på svn_poller. Detta är fortfarande samma gränssnitt, regelbundet pollar förvaret en gång i minuten. I detta fall svn_poller kommer bara åt grenen bagageutrymme. Mystisk parameter split_file=util.svn.split_file_alwaystrunk anger reglerna: hur man bryter upp mappstrukturen svn på grenarna. Han erbjuder dem också relativa vägar. I sin tur split_file_alwaystrunk förenklar processen genom att säga att förvaret endast innehåller bagageutrymme.
В Schemaläggare anges Byt filtervem ser Ingen och associerar en gren med den bagageutrymme enligt en given förening genom split_file_alwaystrunk. Svara på ändringar i bagageutrymme, Lanserar byggare med namn ditt projekt.
egenskaper här behövs det så att administratören får e-postlistor med bygg- och testresultat som ägare till processen.
Steg SLUTRESULTAT-a kassan kan helt ta bort alla filer som finns i den lokala versionen av förvaret Arbetare-A. Och sedan göra det hela svn uppdatering. Läget konfigureras genom parametern läge=full, metod=färsk. Parameter haltOnTailure säger att om svn uppdatering kommer att utföras med ett fel, då bör hela processen med att bygga och testa avbrytas, eftersom ytterligare åtgärder inte är meningsfulla.
6.3 Brev till dig: reportrar har rätt att deklarera
reportrar är en tjänst för att skicka aviseringar via e-post.
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]
Han kan skicka meddelanden .
MailNotifier använder e-post för att skicka meddelanden.
mall_html ställer in textmallen för nyhetsbrevet. HTML används för att skapa uppmärkning. Den modifieras av motorn (kan jämföras med django). BuildBot har en uppsättning variabler vars värden ersätts i mallen under processen att generera meddelandetexten. Dessa variabler är inneslutna i {{ dubbla krulliga klammerparenteser }}. Till exempel, sammanfattning visar status för genomförda operationer, det vill säga framgång eller misslyckande. A projekt kommer att matas ut ditt projekt. Så att använda kontrollkommandon i jinja2, variabler BuildBot-a och python-strängformateringsverktyg kan du skapa ett ganska informativt meddelande.
MailNotifier innehåller följande argument.
fromaddr – adressen från vilken alla kommer att få nyhetsbrevet.
skicka till intresserade användare=True skickar ett meddelande till ägaren och användaren som gjorde förbinda.
slå upp — ett suffix som måste läggas till i namnen på användare som tar emot nyhetsbrevet. Så administration hur användaren kommer att få nyhetsbrevet på adressen [e-postskyddad].
relävärd anger värdnamnet där servern öppnas smtp, en smptPort anger portnumret som lyssnar smtp server.
mode="varning" säger att utskicket endast ska göras om det finns minst ett steg SLUTRESULTAT-a, som slutade med statusfel eller varning. I fallet med framgång finns det inget behov av att skicka ett nyhetsbrev.
extraRecipients innehåller en lista över personer som utskicket ska skickas till förutom ägaren och den som utfört förbinda.
meddelandeFormatter är ett objekt som specificerar meddelandeformatet, dess mall och en uppsättning variabler tillgängliga från jinja2. Alternativ som t.ex wantProperties=Sant и wantSteps=Sant definiera denna uppsättning tillgängliga variabler.
with['services']=[sendMessageToAll] tillhandahåller en lista över tjänster, bland vilka vår kommer att vara reportern.
Vi gjorde det! Grattis
Vi skapade vår egen konfiguration och såg den funktionalitet som den är kapabel till. BuildBot. Detta tror jag är tillräckligt för att förstå om det här verktyget behövs för att skapa ditt projekt. Är du intresserad av honom? Kommer det att vara användbart för dig? Är han bekväm att arbeta med? Då skriver jag inte den här artikeln förgäves.
Och vidare. Jag skulle vilja att det professionella samhället använder BuildBot, blev bredare, manualer översattes och det fanns ännu fler exempel.
Tack alla för er uppmärksamhet. Lycka till.
Källa: will.com