(Billede af fra
Hej!
Mit navn er Evgeny Cherkin, jeg er programmer i udviklerteamet hos minedriftsvirksomheden Polymetal..
Når man påbegynder et større projekt, begynder man at tænke: «Hvilken software er bedst at bruge til vedligeholdelse?». Et IT-projekt gennemgår flere trin, før det frigives i en ny version. Det er en fordel, når kæden af disse trin er automatiseret. Den automatiserede proces til frigivelse af en ny version af et IT-projekt kaldes Continous Integration. BuildBot og har vist sig at være en god hjælper til at udføre denne proces.
I denne artikel vil jeg præsentere en oversigt over funktionerne BuildBot. Hvad er denne software i stand til? Hvordan griber man det an, og hvordan bygger man et godt og EFFEKTIVT ARBEJDSFORHOLD med den? Vores erfaring kan du anvende og oprette en arbejdsserver til bygning og test af dit projekt på din egen maskine.
Indhold
Indhold
1. Hvorfor BuildBot?
Tidligere har jeg set artikler om implementering på habr-e Continous Integration ved hjælp af BuildBot. For eksempel, syntes jeg var den mest informative. Der er et andet eksempel — . Disse artikler kan krydres , og krydret, på engelsk. Samlet set danner det et godt udgangspunkt. Når du har læst disse artikler, vil du sikkert straks have lyst til at BuildBot gøre noget.
Stop! Har nogen overhovedet brugt det i deres projekter? Det viser sig, at ja, de har anvendt det i deres opgaver. Man kan finde brugen af BuildBot også i Google’s kodearkiver.
Hvad er så logikken for folk, der bruger Buildbot? Ведь есть другие инструменты: CruiseControl og Jenkins. Jeg vil svare sådan. Til de fleste opgaver Jenkins er det faktisk nok. I sin tur, BuildBot er mere fleksibel, samtidig med at opgaverne løses lige så enkelt som i Jenkins. Det er op til dig at vælge. Men da vi leder efter et værktøj til et voksende målprojekt, hvorfor så ikke vælge et, der gør det muligt at opnå et system til bygning med interaktivitet og et unikt interface?
For those whose target project is written in Python, the question arises: "Why not choose an integration system with an interface that aligns with the language used in the project?" Now is the time to present the advantages. BuildBot.
So, our "instrumental quartet." I have identified four key features. BuildBot:
- This is an open-source framework under the GPL license.
- This involves using Python as a configuration tool and describing the required actions.
- This allows for receiving feedback from the machine where the assembly occurs.
- Finally, there are minimal requirements for the host. Python and Twisted are required for deployment, and there is no need for a virtual machine or Java machine.
2. Konceptet ledet af BuildMaster
Central to the task distribution architecture is BuildMaster.. It is a service that:
- monitors changes in the project's source tree.
- sends commands for the Worker service to execute for building and testing the project.
- notifies users of the results of the executed actions.
BuildMaster. configured via a file master.cfg. This file is located in the root directory BuildMaster.. Later, I will show how this root is created. The file itself master.cfg contains a Python script that uses calls BuildBot.
The next most important object BuildBot is named SharedWorker. This service can be run on another host with a different OS or on the one where BuildMaster.. It can also exist in a specially prepared virtual environment with its own packages and variables. These virtual environments can be set up using Python utilities like virtualenv, venv..
BuildMaster. translates commands to each SharedWorker-a, and in turn, it executes them. This means that the process of building and testing the project can take place on SharedWorker-a running Windows and on another Worker running Linux.
Checkout of the project's source code occurs on each SharedWorker-a.
3. Installation
So, let's get started. I will use Ubuntu 18.04 as the host. I will set up one BuildMaster.-a and one SharedWorker-a. But first, we need to install Python 3.7:
sudo apt-get update
sudo apt-get install python3.7
For those who need Python 3.7.2 instead of 3.7.1, the following can be done:
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
The next step is to install Twisted. og BuildBot, samt pakker, der muliggør ekstra 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ørste skridt
Tid til at oprette BuildMaster.. Den vil være i vores mappe /home/habr/master.
mkdir master
buildbot create-master master # Egentlig er det her, vi opretter detNæste skridt. Lad os oprette SharedWorker. Den vil være i vores mappe /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Når du starter SharedWorker, så vil den som standard oprette en /home/habr/worker mappe med navnet på projektet, som er angivet i master.cfg. Og i mappen med navnet på projektet vil den oprette et bibliotek build, og derefter vil det lave checkout. Arbejdsmappen for SharedWorker-a vil blive biblioteket /home/habr/yourProject/build.
«Gylden» nøgle
Og nu til det, jeg skrev det forrige afsnit for: skriptet, der Master vil kræve, at SharedWorker-a skal gøre noget eksternt i denne mappe, vil ikke blive udført, da skriptet ikke har ret til at køre. For at løse problemet vil nøgle —umask=0o22, som forhindrer skrivning i denne mappe, men vil bevare kørselsretten. Og det er lige præcis det, vi har brug for.
BuildMaster. og SharedWorker opretter en forbindelse indbyrdes. Nå engang kan det brydes og SharedWorker venter et stykke tid på svar fra BuildMaster.-a. Hvis der ikke kommer noget svar, vil forbindelsen blive genstartet. Nøglen —keepalive=60 er netop nødvendig for at angive den tid, hvorefter connect det genstartes.
5. Konfiguration. Trin-for-trin opskrift
Konfiguration BuildMaster. sker på den maskine, hvor vi udførte kommandoen create-master. I vores tilfælde er det kataloget /home/habr/master. Konfigurationsfilen master.cfg eksisterer endnu ikke, men selve kommandoen har allerede oprettet filen master.cmg.sample. Det er nødvendigt at omdøbe den til master.cfg.sample i master.cfg
mv master.cfg.sample master.cfgLad os åbne denne master.cfg. Og lad os se på, hvad den indeholder. Efter det vil vi prøve at lave vores 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 — den grundlæggende konfiguration for konfigurationsfilen. Den skal være aktiv i konfigurationsfilen. For nemheds skyld introduceres et kaldenavn for brug i konfigurationskoden. ‘c’. Navnene i c[«keyFromDist»] er faste elementer til interaktion med BuildMaster.. Hver nøgle har et tilsvarende objekt som værdi.
5.2 arbejdere
c['workers'] = [worker.Worker("example-worker", "pass")]Denne gang angiver vi BuildMaster.- en liste over SharedWorker-ere. Vi SharedWorker har selv oprettet , ved at angive your-worker-name og adgangskode. Nu skal de samme angives i stedet for example-worker og 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))
Ved nøglen change_source får vi adgang til listen, hvor objektet skal placeres, der skal overvåge kodeprojektets repository. I eksemplet bruges et Git-repository, der overvåges med jævne mellemrum.
Den første parameter er stien til dit repository.
workdir er stien til den mappe, hvor SharedWorker-en vil gemme den lokale version af repositoryet. /home/habr/worker/yourProject/build branch
indholder den specifikke gren i repositoryet, der skal overvåges. pollInterval
indeholder antallet af sekunder, efter hvilke der vil blive forespurgt om ændringer i repositoryet. BuildMaster. Der er flere metoder til at overvåge ændringer i projektets repository.
Den enkleste metode er
Polling Polling, der indebærer, at BuildMaster. den regelmæssigt gør forespørgsler til serveren med repositoryet. Hvis commit ændringerne i repositoryet er blevet reflekteret, så BuildMaster. vil det med en vis forsinkelse oprette et internt objekt Change og sende det til begivenhedshandleren Scheduler, som så vil iværksætte trinene for at bygge og teste projektet på SharedWorker-e. Blandt disse trin vil der blive angivet opdatering repositoryet. Netop på SharedWorker-e vil en lokal kopi af repositoryet blive oprettet. Detaljerne i denne proces vil blive afsløret nedenfor i de næste to afsnit. ( og ).
En endnu mere elegant metode til at følge ændringer i repositoryet er direkte at sende beskeder fra serveren, hvor det er hostet, til BuildMaster.-en om ændringer i koden. I dette tilfælde, så snart en udvikler foretager commit, vil serveren med repositoryet sende en besked til BuildMaster.-en. Og denne vil på sin side opfange det ved at oprette et objekt PBChangeSource. Dette objekt vil herefter blive sendt til Scheduler, som aktiverer trinene for at bygge og teste projektet. En vigtig del af denne metode er arbejdet med hook-scripts på serveren i repositoryet. I skriptet hook-en, der er ansvarlig for at håndtere handlinger ved commit-e, er det nødvendigt at kalde værktøjet sendchange og angive den netværksadresse BuildMaster.-en. Det er også nødvendigt at angive den netværksport, der vil lytte PBChangeSource. PBChangeSource, som i øvrigt er en del af BuildMaster.-en. Denne metode kræver rettigheder admin-a på den server, hvor repositoryet for projektet er placeret. Det vil være nødvendigt at lave en backup af repositoryet først.
5.4 schedulere
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 – er elementet, der fungerer som en trigger, der aktiverer hele kæden for at bygge og teste projektet.
De ændringer, der er blevet registreret change_source, er blevet omdannet i løbet af arbejdet BuildBot-a til et objekt Change og nu bygger hvert Sheduler ud fra dem forespørgsler for at igangsætte byggeprocessen for projektet. Men det bestemmer også, hvornår disse forespørgsler skal sendes videre i køen. Objektet Builder opbevarer en kø af forespørgsler og overvåger status for den aktuelle bygning på en separat SharedWorker-e. Builder det eksisterer både på BuildMaster.-e og på SharedWorker-e. Det sender også fra BuildMaster.-a til SharedWorker-a allerede en specifik build — en række trin, der skal udføres.
Vi ser, at der i dette aktuelle eksempel skabes 2 stykker. Hver har sin egen type. schedulers SingleBranchScheduler
SingleBranchScheduler – en af de mest populære planlægningsklasser. Den overvåger en gren og aktiveres af en registreret ændring i den. Når den ser ændringer, kan den udsætte afsendelsen af anmodningen om bygning (udsætte i en periode, der er angivet i en særlig parameter treeStableTimer). I name angives navnet på planen, som vil blive vist i BuildBot-webinterfacet. I ChangeFilter angives filtret, og når ændringerne i grenen opstår, opfordrer planen til at sende en anmodning om bygning. I builderNames angives navnet builder-a, som vi vil angive lidt senere. Navnet i vores tilfælde vil være det samme som projektets navn: yourProject.
ForceScheduler er en meget enkel ting. Denne type planlægning aktiveres med et museklik gennem BuildBot-webinterfacet. Parametrene har den samme betydning som i SingleBranchScheduler.
P.S. Nr. 3. Måske kan det bruges
Periodisk — dette er en plan, der aktiveres med en bestemt fast tidspermanens. Det ser omtrent sådan ud, når det kaldes
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 angiver tiden for denne periode i sekunder.
BuildFactory opretter en konkret build, som derefter builder sendes til SharedWorker. I BuildFactory angives trinene, der skal udføres SharedWorker-u. Trinene tilføjes ved at kalde metoden addStep
Det første tilføjede trin i dette eksempel — git clean -d -f -f –x, og derefter git checkout. Disse handlinger er indlejret i parameteren metode, som ikke er tydeligt angivet, men underforstår en standardværdi fresh. Parameter mode=’incremental’ angiver, at filer fra den mappe, hvor der sker chechout, mens dem, der ikke findes i repository, forbliver urørt.
Det andet tilføjede trin — er opkaldet til scriptet trial med parameteren hello på siden SharedWorker-a fra mappen /home/habr/worker/yourProject/build c miljøvariablen PATHONPATH=… På denne måde kan du skrive dine scripts og udføre dem på siden SharedWorker-a gennem trin util.ShellCommand. Disse scripts kan placeres direkte i repository. Så når der chechout-e de vil komme ind i /home/habr/worker/yourProject/build. Men der er to "men":
- SharedWorker skal oprettes med nøglen for at forhindre, at den blokerer kørselsrettighederne efter checkout-a.
- Ved git push-e disse scripts skal have egenskaben exacutable, så rettighederne til at udføre scriptet Git ikke tabes efter chechout-e.
5.6 bygninger
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Hvad er Builder blev fortalt . Nu vil jeg fortælle mere om, hvordan man skaber det. BuilderConfig er en konstruktør builder. Der kan angives flere sådanne konstruktører i c[‘builders’] , da dette er en liste over objekter. builder Nu vil vi ændre eksemplet en smule, så det passer bedre til vores opgave. BuildBotc['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory))
Nu vil jeg tale om parametrene,
der angiver navnet BuilderConfig.
name -a. Her kaldte vi det builder. Det betyder, at stien vil blive oprettet på yourProject-e, som netop findes ved dette navn. SharedWorkerworkernames /home/habr/worker/yourProject/build. Sheduler indeholder en liste builder -er. Hver af dem skal tilføjes til
c[‘workers’] factory SharedWorker— den specifikke , der er knyttet til det..
Det vil sende et objekt til at udføre alle de trin, der udgør denne buildHer er arkitekturen for det projekt, jeg foreslår at implementere gennem builderSom versionskontrolsystem vil vi bruge build og få en fungerende kommando. SharedWorker svn build-a.
6. Eksempel på egen konfiguration
. Selve depotet vil befinde sig i en sky. Her er adressen til denne sky: BuildBot
.
svn.host/svn/yourProject/trunk . I skyen er der en konto username:, passwd: -a, vil også ligge i grenen . I skyen er der en konto username: , i en separat mappe userbuildbot/worker_linux adgangskode. Disse scripts ligger i depotet med den gemte egenskab buildexecutable . I skyen er der en konto username:kører på én vært project.hostopbevarer sine filer i mappen, og gemmer dem på følgende sti.
BuildMaster. og SharedWorker . Forbindelsen mellem processerne -a og .BuildMaster. -a foretages via port 4000 gennem protokollen /home/habr/master. SharedWorker -a, det vil sige /home/habr/worker‘pb’ BuildMaster.protokol. SharedWorkerDet målrettede projekt er helt skrevet i Python. Opgaven er at spore dens ændringer, oprette en executable-fil, generere dokumentation og udføre test. I tilfælde af en fejl skal der sendes en mail til alle udviklere om, at der er sket en mislykket handling. BuildBotWebvisningen vi tilslutter til port 80 for . Apache er ikke nødvendigt at installere. Biblioteket
twisted
har allerede en webserver indbygget, BuildBot som det bruger. -a ogFor opbevaring af information til intern brug For mailudsendelse er der brug for en vært smtp.your.domain BuildBot — på den er det tilladt at sende mails fra
projectHost@your.domain BuildBot vil vi bruge sqlite.
uden autentifikation. På værten, ‘smtp’ protokollen lytter på port 1025. Der er to involverede parter i processen: . admin administrerer.. user er den person, der udfører -er.
Executable-filen genereres gennem admin og user. admin administrerer. BuildBotuser er den person, der udfører commit-er.
Executable-fil genereres gennem pyinstaller. Dokumentationen genereres via doxygen.
Til denne arkitektur har jeg skrevet dette 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 for the built release: {{ summary }}</h4>
<p>Service used for the build: {{ workername }}</p>
<p>Project: {{ projects }}</p>
<p>To view the management interface, follow this link: {{ buildbot_url }}</p>
<p>To view the build results, follow this link: {{ build_url }}</p>
<p>Using WinSCP, you can connect to the server at ip:xxx.xx.xxx.xx. Login with habr/password to retrieve the built executable file from the directory ~/worker/yourProject/build/dist.</p>
<p><b>The build was performed using 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'] = "The process of building"
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"
}
For at komme i gang skal du BuildMaster.protokol. SharedWorker-a. Indsæt derefter denne fil master.cfg i /home/habr/master.
Det næste skridt er at starte tjenesten BuildMaster.-a
sudo buildbot start /home/habr/master
Derefter start tjenesten SharedWorker-a
buildbot-worker start /home/habr/worker
Færdig! Nu Buildbot vil overvåge ændringer og reagere på commit-u i . I skyen er der en konto username:, der udfører byggetrinnene og tester projektet med den ovenstående arkitektur.
Nedenfor vil jeg beskrive nogle funktioner i den ovennævnte master.cfg.
6.1 På vej mod sin master.cfg
Under skrivningen af dit master.cfg vil der blive begået mange fejl, så det vil være nødvendigt at læse logfilen. Den opbevares både i BuildMaster.-e c med absolut sti /home/habr/master/twistd.log, samt på siden SharedWorker-a med absolut sti /home/habr/worker/twistd.log. Mens du læser fejl og retter dem, vil det være nødvendigt at genstarte tjenesten BuildMaster.-a. Her er hvordan det gøres:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Arbejde 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)
Lad os først se på svn_poller. Det er den samme interface, der regelmæssigt spørger repositoryet hvert minut. I dette tilfælde svn_poller henviser kun til grenen trunk. Den mystiske parameter split_file=util.svn.split_file_alwaystrunk definerer reglerne: hvordan man opdeler mappestrukturen . I skyen er der en konto username: til grene. Den foreslår relative stier. I sin tur split_file_alwaystrunk forenkler processen ved at sige, at der kun findes trunk.
I Schedulers nævnes der ChangeFilter, som ser None og associerer med en gren trunk i henhold til den angivne association gennem split_file_alwaystrunk. Ved at reagere på ændringer i trunk, starter den builder c med navnet yourProject.
properties her er nødvendig for, at administratoren modtager besked om resultaterne af bygningen og testen som ejer af processen.
Trin build-a checkout kan foretage en fuldstændig sletning af alle filer, der ligger i den lokale version af repositoryet SharedWorker-a. A derefter foretage en fuld svn update. Tilstand er indstillet via parameteren mode=full, method=fresh. Parameter haltOnTailure betyr, at hvis svn update hvis der opstår en fejl, skal hele bygge- og testprocessen pause, da yderligere handlinger ikke giver mening.
6.3 Du har en e-mail: reportere er bemyndiget til at erklære
reporters — er en tjeneste til at sende meddelelser via email.
template_html=u'''
<h4>Status for the built release: {{ summary }}</h4>
<p>Service used for the build: {{ workername }}</p>
<p>Project: {{ projects }}</p>
<p>To view the management interface, follow this link: {{ buildbot_url }}</p>
<p>To view the build results, follow this link: {{ build_url }}</p>
<p>Using WinSCP, you can connect to the server at ip:xxx.xx.xxx.xx. Login with habr/password to retrieve the built executable file from the directory ~/worker/yourProject/build/dist.</p>
<p><b>The build was performed using 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 sende beskeder .
MailNotifier bruger email til at sende meddelelser.
template_html definerer tekstskabelonen til udsendelsen. HTML bruges til at skabe layoutet. Den er modificeret af motoren (kan sammenlignes med django). BuildBot har et sæt variabler, hvis værdier indsættes i skabelonen under udformningen af beskedteksten. Disse variabler er indsat i {{ dobbelte krøllede parenteser }}. For eksempel, resumé opgiver status for udførte handlinger, det vil sige success eller failure. Og projects vil udskrive yourProject. Derved kan man ved hjælp af kontrolkommandoer i jinja2, variablerne BuildBot-a og formateringsmidler i python skabe en ganske informativ meddelelse.
MailNotifier indeholder følgende argumenter.
fromaddr – adressen, hvorfra alle vil modtage udsendelsen.
sendToInterestedUsers=True sender beskeden til ejer og brugeren, der har foretaget commit.
lookup — suffikset, der skal tilføjes brugernavne, der modtager udsendelsen. Så admin fordi brugeren vil modtage udsendelsen på adressen admin@your.domain.
relayhost definerer navnet på værten, hvor serveren er åben . user er den person, der udfører, a smptPort definerer portnummeret, som lytter på . user er den person, der udfører server.
mode=«warning» angiver, at udsendelsen kun skal foretages, hvis der er mindst ét skridt build-a, der er afsluttet med status failure eller warning. I tilfælde af success er der ikke behov for udsendelse.
extraRecipients indeholder en liste over personer, der skal modtage udsendelse udover ejeren og den person, der har foretaget commit.
messageFormatter er et objekt, der definerer beskedformatet, dens skabelon og sættet af variabler tilgængelige fra jinja2. Sådanne parametre som wantProperties=True og wantSteps=True definerer dette sæt af tilgængelige variabler.
s[‘services’]=[sendMessageToAll] giver en liste over tjenester, herunder vores reporter.
Vi gjorde det! Tillykke
Vi har skabt vores egen konfiguration og set den funktionalitet, som BuildBoter i stand til. Dette, tror jeg, er nok til at afgøre, om dette værktøj er nødvendigt for at skabe dit projekt. Er det interessant for dig? Vil det være nyttigt? Er det nemt at arbejde med? Så skrev jeg ikke denne artikel forgæves.
Og forresten. Jeg ville ønske, at det professionelle fællesskab, der bruger BuildBot, blev bredere, at manualerne blev oversat, og at der kom flere eksempler.
Tak til alle for opmærksomheden. Held og lykke.
Kilde: habr.com
