(Billede af fra
Hi!
Mit navn er Evgeniy Cherkin, Jeg er programmør på et udviklingsteam hos et mineselskab Polymetal.
Når du starter et stort projekt, begynder du at tænke: "Hvilken software er bedst at bruge til at vedligeholde det?" Et it-projekt gennemgår en række faser, før det udsender den næste version. Det er godt, når kæden af disse stadier er automatiseret. Den automatiserede proces med at frigive en ny version af selve et it-projekt kaldes Kontinuerlig integration. BuildBot viste sig at være en god assistent for os i implementeringen af denne proces.
I denne artikel besluttede jeg at give et overblik over mulighederne BuildBot. Hvad er denne software i stand til? Hvordan henvender man sig til ham, og hvordan opbygger man et normalt EFFEKTIVT ARBEJDSRELATION med ham? Du kan selv anvende vores erfaring ved at oprette en fungerende service til at bygge og teste dit projekt på din maskine.
Indhold
Indhold
1. Hvorfor BuildBot?
Tidligere på habr-e stødte jeg på artikler om implementering Kontinuerlig integration med BuildBot. F.eks, Jeg fandt det mest informativt. Der er et andet eksempel - . Disse artikler kan krydres Og derefter på engelsk. Coupéen er et godt udgangspunkt. Efter at have læst disse artikler, vil du sikkert straks have noget på BuildBot gør.
Hold op! Er der nogen, der rent faktisk har brugt det i deres projekter? Det viser sig ja anvendt det i deres opgaver. Kan findes bruge BuildBot og i Googles kodearkiv.
Så hvad er logikken i, at folk bruger Buildbot? Der er trods alt andre værktøjer: Fartpilot и Jenkins. Jeg vil svare på denne måde. Til de fleste opgaver Jenkins og sandheden vil være nok. Til gengæld BuildBot - mere adaptiv, mens problemer løses der så enkelt som i Jenkins. Det er dit valg. Men da vi leder efter et værktøj til et udviklende målprojekt, hvorfor så ikke vælge et, der vil gøre det muligt, startende fra enkle trin, at opnå et byggesystem, der har interaktivitet og en unik grænseflade.
For dem, hvis målprojekt er skrevet i python, opstår spørgsmålet: "Hvorfor ikke vælge et integrationssystem, der har en klar grænseflade i forhold til det sprog, der bruges i projektet?" Og nu er det tid til at præsentere fordelene BuildBot.
Altså vores "instrumentalkvartet". For mig selv har jeg identificeret fire funktioner BuildBot:
- Det er en open source-ramme under GPL-licens
- Dette er brugen af python som et konfigurationsværktøj og beskrivelse af de nødvendige handlinger
- Dette er en mulighed for at få svar fra den maskine, som monteringen foregår på
- Dette er endelig minimumskravene til en vært. Implementering kræver python og snoet, og kræver ikke en virtuel maskine og java-maskine.
2. Koncept ledet af BuildMaster
Centralt i opgavefordelingsarkitekturen er BuildMaster. Det er en service, der:
- holder styr ændringer i projektets kildetræ
- sender kommandoer, der skal udføres af Worker-tjenesten for at bygge projektet og teste det
- giver besked brugere om resultaterne af truffet handlinger
BuildMaster konfigureret via fil master.cfg. Denne fil er i roden BuildMaster. Senere vil jeg vise, hvordan denne rod skabes. Selve filen master.cfg indeholder et python-script, der bruger opkald BuildBot.
Næst vigtigste objekt BuildBot Det har navnet Worker. Denne tjeneste kan lanceres på en anden vært med et andet OS, eller måske på det, hvor BuildMaster. Det kan også eksistere i et specielt forberedt virtuelt miljø med sine egne pakker og variabler. Disse virtuelle miljøer kan forberedes ved hjælp af python-værktøjer som virtualenv, venv.
BuildMaster udsender kommandoer til alle Worker-y, og han opfylder dem til gengæld. Det vil sige, at det viser sig, at processen med at bygge og teste et projekt kan fortsætte Worker-e kører Windows og på en anden Worker der kører Linux.
Checkout projektkildekoder forekommer på hver Worker-e.
3. Installation
Så lad os gå. Jeg vil bruge Ubuntu 18.04 som vært. Jeg sætter en på den BuildMaster-en og en Worker-en. Men først skal du installere python3.7:
sudo apt-get update
sudo apt-get install python3.7
For dem, der har brug for python3.7.2 i stedet for 3.7.1, kan du gøre følgende:
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
Det næste trin er at installere Tweeted и BuildBot, samt pakker, der giver dig mulighed for at bruge yderligere 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 skabe BuildMaster. Det vil være i vores folder /hjem/haver/mester.
mkdir master
buildbot create-master master # Собственно сдесь и создаемNæste skridt. Lad os skabe Worker. Det vil være i vores folder /hjem/haver/arbejder.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Når du løber Worker, så vil den som standard oprette i /hjem/haver/arbejder mappe med navnet på projektet, som er angivet i master.cfg. Og i mappen med navnet på projektet vil den oprette en mappe bygge, og vil fortsætte med at gøre det gå til kassen. Arbejdsmappe til Worker-og det bliver en mappe /home/habr/ditprojekt/byg.
"Den gyldne nøgle
Og nu, hvad jeg skrev det forrige afsnit til: et manuskript, der Mestre vil kræve fra Worker-og udført eksternt i denne mappe vil ikke blive udført, fordi scriptet ikke har tilladelser til at køre. For at rette op på situationen skal du bruge en nøgle --umask=0o22, som forbyder skrivning til denne mappe, men vil bevare startrettighederne. Og det er alt, hvad vi har brug for.
BuildMaster и Worker skabe forbindelse til hinanden. Det sker, at det brækker af og Worker venter et stykke tid på svar fra BuildMaster-EN. Hvis der ikke er noget svar, genstartes forbindelsen. Nøgle --keepalive=60 manglede bare at angive tidspunktet, hvorefter connect genstarter.
5. Konfiguration. Trin for trin opskrift
Konfiguration BuildMaster udføres på den side af maskinen, hvor vi udførte kommandoen skabe-mester. I vores tilfælde er dette en mappe /hjem/haver/mester. Konfigurationsfil master.cfg eksisterer ikke endnu, men selve kommandoen har allerede oprettet filen master.cmg.sample. Du skal omdøbe den til master.cfg.sample в master.cfg
mv master.cfg.sample master.cfgLad os åbne denne master.cfg. Og lad os se på, hvad det består af. Og efter det, lad os 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 — grundlæggende ordbog for konfigurationsfilen. Det skal inkluderes i konfigurationsfilen. For at lette brugen er der indført et alias i konfigurationskoden "c". Titler в c["keyFromDist"] er faste elementer til interaktion med BuildMaster. For hver nøgle erstattes det tilsvarende objekt som en værdi.
arbejdstagere 5.2
c['workers'] = [worker.Worker("example-worker", "pass")]Denne gang angiver vi BuildMaster-y liste over Worker-s. Mig selv Worker vi skabte , angiver du-arbejder-navn и adgangskode. Nu skal de specificeres i stedet eksempel-arbejder и passerer .
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 nøgle change_source ordbog c får vi adgang til listen, hvor vi vil placere et objekt, der poller depotet med projektets kildekode. Eksemplet bruger et Git-lager, der polles med bestemte intervaller.
Det første argument er stien til dit lager.
arbejdsdir repræsenterer stien til mappen på siden Worker-en slægtning til stien /hjem/habr/arbejder/ditprojekt/byg git gemmer den lokale version af depotet.
gren indeholder en specifik gren i depotet, som skal følges.
pollInterval indeholder det antal sekunder, hvorefter BuildMaster vil polle lageret for ændringer.
Der er flere metoder til at spore ændringer i et projekts lager.
Den enkleste metode er polling, hvilket indebærer det BuildMaster spørger periodisk serveren med lageret. Hvis begå afspejlede ændringerne i depotet BuildMaster vil oprette et internt objekt med en vis forsinkelse Skift og send det til hændelseshandleren Scheduler, som vil lancere trinene til at bygge og teste projektet på Worker-e. Blandt disse trin vil blive angivet opdatering depot. Præcis på WorkerDette vil oprette en lokal kopi af depotet. Detaljerne i denne proces vil blive dækket nedenfor i de næste to afsnit. ( и ).
En endnu mere elegant metode til at spore ændringer til et lager er at sende beskeder direkte fra serveren, der hoster det til BuildMaster- om at ændre projektets kildekoder. I dette tilfælde, så snart udvikleren gør begå, vil serveren med projektlageret sende en besked BuildMaster-y. Og han vil til gengæld opsnappe det ved at skabe et objekt PBChangeSource. Dernæst vil dette objekt blive overført til Scheduler, som aktiverer trinene til at bygge projektet og teste det. En vigtig del af denne metode er at arbejde med krog-server scripts i depotet. I manuskriptet krog-a, ansvarlig for at behandle handlinger, når begå-e, du skal ringe til værktøjet send ændring og angiv netværksadressen BuildMaster-EN. Du skal også angive den netværksport, der vil lytte PBChangeSource. PBChangeSource, i øvrigt er en del BuildMaster-EN. Denne metode kræver tilladelse admin-a på den server, hvor projektdepotet er placeret. Du skal først lave en sikkerhedskopi af depotet.
5.4 skemalæggere
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"]))
skemalæggere – dette er et element, der fungerer som en trigger, der starter hele kæden af montage og test af projektet.
De ændringer, der blev registreret change_source, transformeret i processen med arbejdet BuildBot-a at gøre indsigelse Skift og nu hver Sheduler baseret på dem opbygger den anmodninger om at starte projektopbygningsprocessen. Det bestemmer dog også, hvornår disse anmodninger overføres videre til køen. Et objekt Builder gemmer en kø af anmodninger og sporer status for den aktuelle samling på en separat Worker-er. Builder eksisterer på BuildMaster-e og videre Worker-e. Han sender med BuildMaster-a på Worker-og allerede specifik bygge - en række trin, der skal følges.
Vi ser, at i det aktuelle eksempel sådan skemalæggere Der laves 2 stk. Desuden har hver sin egen type.
SingleBranchScheduler – en af de mest populære klasser på skemaet. Den overvåger én gren og udløses af en registreret ændring i den. Når han ser ændringer, kan han forsinke afsendelsen af byggeanmodningen (udskyde for den periode, der er angivet i den særlige parameter treeStableTimer). den navn angiver navnet på den tidsplan, der vil blive vist i BuildBot-webgrænseflade. I Skift filter der sættes et filter, efter bestået hvilke ændringer i grenen, der beder tidsplanen om at sende en anmodning om byggeri. I bygherrens navne navn er angivet Builder-a, som vi sætter lidt senere. Navnet i vores tilfælde vil være det samme som projektnavnet: dit projekt.
ForceScheduler en meget simpel ting. Denne type tidsplan udløses af et museklik igennem BuildBot-webgrænseflade. Parametrene har samme essens som i SingleBranchScheduler.
PS nr. 3. Måske vil det komme til nytte
Periodisk er et skema, der kører med en bestemt tidsbestemt frekvens. Opkaldet ser sådan ud
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 tidspunktet for denne periodicitet i sekunder.
BuildFactory skaber en bestemt bygge, som så Builder sender til Worker. I BuildFactory angiver de trin, der skal følges Worker-y. Trin tilføjes ved at kalde metoden addStep
Det første tilføjede trin i dette eksempel er git clean -d -f -f -x, så git checkout. Disse handlinger er inkluderet i parameteren metode, som ikke er tydeligt angivet, men antyder en standardværdi frisk. Parameter mode='incremental' angiver, at filerne er fra den mappe, hvor chechout, mens den mangler fra depotet, forbliver urørt.
Det andet tilføjede trin er at kalde scriptet retssag med parameter Hej på siden Worker-a fra bibliotek /hjem/habr/arbejder/ditprojekt/byg med miljøvariablen PATHONPATH=... Du kan således skrive dine egne scripts og udføre dem ved siden af Worker-et hvert skridt util.ShellCommand. Disse scripts kan placeres direkte i depotet. Så kl chechout-e vil de falde i /hjem/habr/arbejder/ditprojekt/byg. Men så er der to "men":
- Worker skal oprettes med en nøgle så det ikke blokerer for udførelsesrettigheder efter gå til kassen-a.
- på git push-e af disse scripts skal du bruge for at specificere egenskaben eksaktbarså det senere chechout-e mistede ikke retten til at udføre Git-scriptet.
5.6 bygherrer
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Om hvad det er Builder Fik fortalt . Nu vil jeg fortælle dig mere detaljeret om, hvordan du opretter det. BuilderConfig er konstruktør Builder. Sådanne designere i c['byggere'] du kan angive flere, da dette er et ark med objekter Builder type. Lad os nu omskrive eksemplet fra BuildBot, hvilket bringer det tættere på vores opgave.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Nu vil jeg fortælle dig om parametrene BuilderConfig.
navn angiver navnet Builder-en. Her har vi navngivet det dit projekt. Det betyder, at på Worker- netop denne vej vil blive skabt /hjem/habr/arbejder/ditprojekt/byg. Sheduler leder efter Builder bare ved dette navn.
arbejdernavne indeholder ark Worker-s. Hver af dem skal tilføjes c['arbejdere'].
fabrik - specifik bygge, som den er forbundet med Builder. Han sender genstanden bygge på Worker for at fuldføre alle de trin, der er inkluderet i dette bygge-a.
6. Eksempel på din egen konfiguration
Her er eksemplet på projektarkitekturen, som jeg foreslår at implementere via BuildBot
.
Vi vil bruge som et versionskontrolsystem svn. Selve depotet vil være placeret i en form for sky. Her er adressen på denne sky . I skyen nedenunder svn der er et kontobrugernavn: bruger, adgangskode: adgangskode. Scripts, der repræsenterer trin bygge-a vil også være i filialen svn, i en separat mappe buildbot/worker_linux. Disse scripts er placeret i lageret med den gemte egenskab eksekverbar.
BuildMaster и Worker køre på den samme vært projekt.vært .BuildMaster gemmer sine filer i en mappe /hjem/haver/mester. Worker den er gemt i følgende sti /hjem/haver/arbejder. Proceskommunikation BuildMaster-en og Worker-a udføres gennem port 4000 i henhold til protokollen BuildBot-a, altså 'pb' protokol.
Målprojektet er udelukkende skrevet i Python. Opgaven er at spore dens ændringer, oprette en eksekverbar fil, generere dokumentation og udføre test. I tilfælde af fejl skal alle udviklere sende en besked via e-mail om, at der er en mislykket handling.
Web visning BuildBot vi vil forbinde til port 80 for projekt.vært. Det er ikke nødvendigt at installere Apatch. Som en del af biblioteket snoet der er allerede en webserver, BuildBot bruger det.
Til at gemme interne oplysninger til BuildBot vi vil bruge SQLite.
Der kræves en vært for at sende mail smtp.dit.domæne - det giver mulighed for at sende breve fra post [e-mail beskyttet] uden autentificering. Også på værten 'smtp ' Referatet høres på post 1025.
Der er to personer involveret i processen: admin и bruger. admin administrerer BuildBot. bruger er den person, der forpligter sig begå-s.
Eksekverbar fil genereres via pyinstaller. Dokumentation genereres via doxygen.
Til denne arkitektur skrev jeg 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>Статус построенного релиза: {{ 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"
}
For at komme i gang skal du BuildMaster-en og Worker-en. Indsæt derefter denne fil master.cfg в /hjem/haver/mester.
Det næste trin er at starte tjenesten BuildMasters
sudo buildbot start /home/habr/master
Start derefter tjenesten Worker-a
buildbot-worker start /home/habr/worker
Parat! Nu Buildbot vil spore ændringer og udløse begå-y ind svn, udfører trinene til at bygge og teste et projekt med ovenstående arkitektur.
Nedenfor vil jeg beskrive nogle funktioner i ovenstående master.cfg.
6.1 På vej til din master.cfg
Mens jeg skriver min master.cfg Der vil blive lavet mange fejl, så det er nødvendigt at læse logfilen. Den opbevares som BuildMaster-ec absolut sti /home/habr/master/twistd.log, og på siden Worker-en med absolut sti /home/habr/worker/twistd.log. Når du læser fejlen og retter den, skal du genstarte tjenesten BuildMaster-en. Sådan gøres det:
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)
Først, lad os tage et kig på svn_poller. Dette er stadig den samme grænseflade, der regelmæssigt poller depotet en gang i minuttet. I dette tilfælde svn_poller kun adgang til filialen bagagerum. Mystisk parameter split_file=util.svn.split_file_alwaystrunk sætter reglerne: hvordan opdeles mappestrukturen svn på grenene. Han tilbyder dem også relative veje. I sin tur split_file_alwaystrunk forenkler processen ved at sige, at depotet kun indeholder bagagerum.
В Planlæggere angivet Skift filterhvem ser Ingen og forbinder en filial med den bagagerum ifølge en given forening igennem split_file_alwaystrunk. Reagerer på ændringer i bagagerum, Lancerer Builder med navn dit projekt.
egenskaber her er det nødvendigt, så administratoren modtager mailinglister med bygge- og testresultater som ejer af processen.
trin bygge-a gå til kassen i stand til fuldstændig at slette alle filer, der er placeret i den lokale version af depotet Worker-EN. Og så gør det hele svn opdatering. Tilstanden konfigureres gennem parameteren tilstand = fuld, metode=frisk. Parameter haltOnTailure siger, at hvis svn opdatering vil blive udført med en fejl, så skal hele processen med at bygge og teste blive suspenderet, da yderligere handlinger ikke giver mening.
6.3 Brev til dig: journalister er bemyndiget til at erklære
journalister er en tjeneste til at sende meddelelser via e-mail.
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 sende beskeder .
MailNotifier bruger e-mail til at sende meddelelser.
template_html sætter tekstskabelonen til nyhedsbrevet. HTML bruges til at lave markup. Det er modificeret af motoren (kan sammenlignes med django). BuildBot har et sæt variabler, hvis værdier erstattes af skabelonen under processen med at generere beskedteksten. Disse variabler er omgivet af {{ dobbelte krøllede parenteser }}. For eksempel, resumé viser status for afsluttede operationer, det vil sige succes eller fiasko. EN projekter vil udskrive dit projekt. Så ved at bruge kontrolkommandoer i jinja2, variabler BuildBot-a og python streng formateringsværktøjer, kan du oprette en ganske informativ besked.
MailNotifier indeholder følgende argumenter.
fraaddr – den adresse, hvorfra alle modtager nyhedsbrevet.
sendTil Interesserede Brugere=True sender en besked til ejeren og brugeren, der har lavet begå.
kig op — et suffiks, der skal tilføjes til navnene på brugere, der modtager nyhedsbrevet. Så admin hvordan brugeren modtager nyhedsbrevet på adressen [e-mail beskyttet].
relævært angiver værtsnavnet, som serveren åbnes på smtp, en smptPort angiver portnummeret, der lytter smtp server.
mode="advarsel" siger, at udsendelsen kun skal ske, hvis der er mindst et trin bygge-a, som endte med statusfejl eller advarsel. I tilfælde af succes er der ingen grund til at sende et nyhedsbrev.
ekstramodtagere indeholder en liste over personer, som forsendelsen skal sendes til ud over ejeren og den person, der har udført begå.
messageFormatter er et objekt, der specificerer meddelelsesformatet, dets skabelon og et sæt variabler, der er tilgængelige fra jinja2. Muligheder som f.eks wantProperties=Sandt и wantSteps=Sandt definere dette sæt af tilgængelige variabler.
with['services']=[sendMessageToAll] giver en liste over tjenester, blandt hvilke vores vil være reporter.
Vi gjorde det! Tillykke
Vi lavede vores egen konfiguration og så den funktionalitet, den er i stand til. BuildBot. Dette, tror jeg, er nok til at forstå, om dette værktøj er nødvendigt for at skabe dit projekt. Er du interesseret i ham? Vil det være nyttigt for dig? Er han behagelig at arbejde med? Så skriver jeg ikke denne artikel forgæves.
Og videre. Jeg vil gerne have, at det professionelle fællesskab bruger BuildBot, blev bredere, manualer blev oversat, og der var endnu flere eksempler.
Tak til jer alle for jeres opmærksomhed. Held og lykke.
Kilde: www.habr.com