(Bilde av fra
Hei!
Mitt navn er Evgeniy Cherkin, Jeg er programmerer i et utviklingsteam hos et gruveselskap Polymetall.
Når du starter et stort prosjekt, begynner du å tenke: "Hvilken programvare er best å bruke for å vedlikeholde den?" Et IT-prosjekt går gjennom en rekke stadier før neste versjon utgis. Det er bra når kjeden av disse stadiene er automatisert. Den automatiserte prosessen med å gi ut en ny versjon av et IT-prosjekt i seg selv kalles Kontinuerlig integrasjon. BuildBot viste seg å være en god assistent for oss i implementeringen av denne prosessen.
I denne artikkelen bestemte jeg meg for å gi en oversikt over mulighetene BuildBot. Hva er denne programvaren i stand til? Hvordan nærme seg ham og hvordan bygge et normalt EFFEKTIVT ARBEIDSFORHOLD med ham? Du kan bruke vår erfaring selv ved å lage en fungerende tjeneste for å bygge og teste prosjektet ditt på maskinen din.
Innhold
Innhold
1. Hvorfor BuildBot?
Tidligere på habr-e kom jeg over artikler om implementering Kontinuerlig integrasjon med BuildBot. f.eks. Jeg fant det mest informativt. Det er et annet eksempel - . Disse artiklene kan krydres Og etter det, på engelsk. Kupéen er et godt utgangspunkt. Etter å ha lest disse artiklene vil du sannsynligvis umiddelbart ha noe på BuildBot å gjøre.
Stoppe! Har noen faktisk brukt det i sine prosjekter? Det viser seg ja brukt det i sine oppgaver. Kan bli funnet bruke BuildBot og i Googles kodearkiv.
Så hva er logikken til folk som bruker Byggebot? Tross alt er det andre verktøy: CruiseControl и Jenkins. Jeg vil svare på denne måten. For de fleste oppgaver Jenkins og sannheten vil være nok. I sin tur, BuildBot - mer tilpasningsdyktig, mens problemer løses der så enkelt som i Jenkins. Valget er ditt. Men siden vi er på utkikk etter et verktøy for et utviklende målprosjekt, hvorfor ikke velge et som vil tillate, fra enkle trinn, å få et byggesystem som har interaktivitet og et unikt grensesnitt.
For de hvis målprosjekt er skrevet i python, oppstår spørsmålet: "Hvorfor ikke velge et integreringssystem som har et tydelig grensesnitt med tanke på språket som brukes i prosjektet?" Og nå er det på tide å presentere fordelene BuildBot.
Så vår "instrumentalkvartett". For meg selv har jeg identifisert fire funksjoner BuildBot:
- Det er et rammeverk med åpen kildekode under GPL-lisens
- Dette er bruken av python som et konfigurasjonsverktøy og beskrivelse av de nødvendige handlingene
- Dette er en mulighet til å få svar fra maskinen som monteringen foregår på
- Dette er til slutt minimumskravene for en vert. Utrulling krever python og vridd, og krever ikke en virtuell maskin og java-maskin.
2. Konsept ledet av BuildMaster
Sentralt i oppgavefordelingsarkitekturen er BuildMaster. Det er en tjeneste som:
- holder oversikt endringer i prosjektkildetreet
- sender kommandoer som skal utføres av Worker-tjenesten for å bygge prosjektet og teste det
- varsler brukere om resultatene av handlinger som er utført
BuildMaster konfigurert via fil master.cfg. Denne filen er i roten BuildMaster. Senere skal jeg vise hvordan denne roten blir til. Selve filen master.cfg inneholder et python-skript som bruker anrop BuildBot.
Neste viktigste objekt BuildBot Den har navnet Worker. Denne tjenesten kan lanseres på en annen vert med et annet OS, eller kanskje på den der BuildMaster. Den kan også eksistere i et spesielt forberedt virtuelt miljø med egne pakker og variabler. Disse virtuelle miljøene kan forberedes ved å bruke python-verktøy som virtualenv, venv.
BuildMaster sender kommandoer til alle Worker-y, og han på sin side oppfyller dem. Det vil si at det viser seg at prosessen med å bygge og teste et prosjekt kan fortsette Worker-e som kjører Windows og på en annen Worker som kjører Linux.
Sjekk ut prosjektkildekoder forekommer på hver Worker-e.
3. Installasjon
Så la oss gå. Jeg kommer til å bruke Ubuntu 18.04 som vert. Jeg legger en på den BuildMaster-en og en Worker-en. Men først må du installere python3.7:
sudo apt-get update
sudo apt-get install python3.7
For de som trenger python3.7.2 i stedet for 3.7.1, kan du gjø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
Neste trinn er å installere Tvitret и BuildBot, samt pakker som lar deg bruke tilleggsfunksjonalitet 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 trinn
På tide å skape BuildMaster. Det vil ligge i mappen vår /hjem/habr/mester.
mkdir master
buildbot create-master master # Собственно сдесь и создаемNeste steg. La oss skape Worker. Det vil ligge i mappen vår /hjem/habr/arbeider.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Når du løper Worker, så vil den som standard opprettes i /hjem/habr/arbeider mappe med navnet på prosjektet, som er spesifisert i master.cfg. Og i mappen med navnet på prosjektet vil det opprette en katalog bygge, og vil fortsette å gjøre det kassen. Arbeidskatalog for Worker-og det vil bli en katalog /home/habr/dittProsjekt/bygg.
"Gylden nøkkel
Og nå det jeg skrev forrige avsnitt for: et manus som Master vil kreve fra Worker-og gjort eksternt i denne katalogen vil ikke bli utført fordi skriptet ikke har rettighetene til å kjøre. For å rette opp situasjonen trenger du en nøkkel --umask=0o22, som forbyr skriving til denne katalogen, men vil beholde lanseringsrettighetene. Og det er alt vi trenger.
BuildMaster и Worker etablere en forbindelse med hverandre. Det hender at den bryter av og Worker venter en stund på svar fra BuildMaster-EN. Hvis det ikke er noe svar, startes tilkoblingen på nytt. Nøkkel --keepalive=60 trengte bare å angi tiden etterpå koble starter på nytt.
5. Konfigurasjon. Steg for steg oppskrift
Konfigurasjon BuildMaster utføres på siden av maskinen der vi utførte kommandoen skape-mester. I vårt tilfelle er dette en katalog /hjem/habr/mester. Konfigurasjonsfil master.cfg eksisterer ikke ennå, men selve kommandoen har allerede opprettet filen master.cmg.sample. Du må gi det nytt navn til master.cfg.sample в master.cfg
mv master.cfg.sample master.cfgLa oss åpne denne master.cfg. Og la oss se på hva den består av. Og etter det, la oss prøve å lage vår egen konfigurasjonsfil.
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 — grunnleggende ordbok for konfigurasjonsfilen. Den må inkluderes i konfigurasjonsfilen. For enkel bruk er et alias introdusert i konfigurasjonskoden "c". Titler в c["keyFromDist"] er faste elementer for samhandling med BuildMaster. For hver nøkkel erstattes det tilsvarende objektet som en verdi.
5.2 arbeidere
c['workers'] = [worker.Worker("example-worker", "pass")]Denne gangen indikerer vi BuildMaster-y liste over Worker-s. Meg selv Worker vi skapte , som indikerer du-arbeider-navn и passord. Nå må de spesifiseres i stedet eksempel-arbeider и passere .
5.3 endre_kilde
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økkel endre_kilde ordbok c får vi tilgang til listen der vi ønsker å plassere et objekt som poller depotet med prosjektets kildekode. Eksemplet bruker et Git-depot som polles med bestemte intervaller.
Det første argumentet er veien til depotet ditt.
arbeidsdir representerer banen til mappen på siden Worker-en slektning til stien /hjem/habr/arbeider/dittProsjekt/bygg git vil lagre den lokale versjonen av depotet.
gren inneholder en spesifikk gren i depotet som bør følges.
pollInterval inneholder antall sekunder etterpå BuildMaster vil spørre depotet for endringer.
Det er flere metoder for å spore endringer i et prosjekts depot.
Den enkleste metoden er Polling, som innebærer det BuildMaster spør med jevne mellomrom serveren med depotet. Hvis forplikte reflekterte endringene i depotet, da BuildMaster vil opprette et internt objekt med en viss forsinkelse Endring og send den til hendelsesbehandleren Scheduler, som vil lansere trinnene for å bygge og teste prosjektet på Worker-e. Blant disse trinnene vil bli indikert Oppdater oppbevaringssted. Akkurat på WorkerDette vil opprette en lokal kopi av depotet. Detaljene i denne prosessen vil bli dekket nedenfor i de neste to delene. ( и ).
En enda mer elegant metode for å spore endringer i et depot er å sende meldinger direkte fra serveren som den er vert for BuildMaster- om å endre prosjektets kildekoder. I dette tilfellet, så snart utvikleren gjør forplikte, vil serveren med prosjektlageret sende en melding BuildMaster-y. Og han vil på sin side avskjære det ved å lage et objekt PBChangeSource. Deretter vil dette objektet bli overført til Scheduler, som aktiverer trinnene for å bygge prosjektet og teste det. En viktig del av denne metoden er å jobbe med krok-serverskript i depotet. I manuset krok-a, ansvarlig for behandling av handlinger når forplikte-e, du må ringe verktøyet sendendring og spesifiser nettverksadressen BuildMaster-EN. Du må også spesifisere nettverksporten som skal lytte PBChangeSource. PBChangeSource, forresten, er en del BuildMaster-EN. Denne metoden krever tillatelse admin-a på serveren der prosjektlageret er plassert. Du må først ta en sikkerhetskopi av depotet.
5.4 planleggere
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"]))
planleggere – dette er et element som fungerer som en trigger som starter hele kjeden med montering og testing av prosjektet.
De endringene som ble registrert endre_kilde, forvandlet i prosessen med arbeidet BuildBot-a å protestere Endring og nå hver Sheduler basert på dem, bygger den forespørsler for å starte prosjektbyggingsprosessen. Den bestemmer imidlertid også når disse forespørslene overføres videre til køen. En gjenstand Builder lagrer en kø med forespørsler og sporer statusen til gjeldende sammenstilling på en separat Worker-er. Builder eksisterer på BuildMaster-e og videre Worker-e. Han sender med BuildMaster-a på Worker-og allerede spesifikk bygge - en rekke trinn som må følges.
Vi ser at i det aktuelle eksempelet slik planleggere 2 stykker er laget. Dessuten har hver sin egen type.
SingleBranchScheduler – en av de mest populære timene på timeplanen. Den overvåker én gren og utløses av en registrert endring i den. Når han ser endringer, kan han utsette sendingen av byggeforespørselen (utsette for perioden spesifisert i den spesielle parameteren treeStableTimer). I navn angir navnet på tidsplanen som skal vises i BuildBot-webgrensesnitt. I Endre filter et filter settes, etter bestått hvilke endringer i grenen som ber tidsplanen om å sende en forespørsel om konstruksjon. I byggherrenavn navn er angitt bygger-a, som vi skal sette litt senere. Navnet i vårt tilfelle vil være det samme som prosjektnavnet: ditt prosjekt.
ForceScheduler en veldig enkel ting. Denne typen tidsplan utløses av et museklikk BuildBot-webgrensesnitt. Parametrene har samme essens som i SingleBranchScheduler.
PS nr. 3. Kanskje det kommer godt med
Periodisk er en tidsplan som kjører med en viss tidsbestemt frekvens. Samtalen ser omtrent slik ut
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 angir tidspunktet for denne periodisiteten i sekunder.
BuildFactory skaper en bestemt bygge, som da bygger sender til Worker. I BuildFactory angir trinnene som skal følges Worker-y. Trinn legges til ved å kalle metoden addStep
Det første trinnet som legges til i dette eksemplet er git clean -d -f -f -x, da git kassa. Disse handlingene er inkludert i parameteren metode, som ikke er tydelig angitt, men antyder en standardverdi fersk. Parameter mode='inkrementell' indikerer at filene er fra katalogen der chechout, mens den mangler fra depotet, forblir urørt.
Det andre trinnet som legges til er å kalle skriptet prøve med parameter Hallo på siden Worker-a fra katalogen /hjem/habr/arbeider/dittProsjekt/bygg med miljøvariabelen PATHONPATH=... Dermed kan du skrive dine egne skript og kjøre dem ved siden av Worker-a hvert skritt util.ShellCommand. Disse skriptene kan plasseres direkte i depotet. Så kl chechout-e vil de falle inn i /hjem/habr/arbeider/dittProsjekt/bygg. Men så er det to "men":
- Worker må opprettes med en nøkkel slik at den ikke blokkerer utførelsesrettigheter etter kassen-a.
- ved git push-e av disse skriptene du trenger for å spesifisere egenskapen eksaktbarslik at senere chechout-e mistet ikke retten til å kjøre Git-skriptet.
5.6 byggherrer
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Om hva som er Builder ble fortalt . Nå vil jeg fortelle deg mer detaljert om hvordan du lager det. BuilderConfig er konstruktør bygger. Slike designere i c['byggere'] du kan spesifisere flere, siden dette er et ark med objekter bygger type. La oss nå omskrive eksemplet fra BuildBot, og bringer det nærmere vår oppgave.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Nå skal jeg fortelle deg om parametrene BuilderConfig.
navn spesifiserer navnet bygger-en. Her ga vi den navnet ditt prosjekt... Dette betyr at på Worker– akkurat denne veien vil bli skapt /hjem/habr/arbeider/dittProsjekt/bygg. Sheduler ser etter bygger bare med dette navnet.
arbeidernavn inneholder ark Worker-s. Hver av dem må legges til c['arbeidere'].
fabrikk - spesifikk bygge, som den er knyttet til bygger. Han vil sende objektet bygge på Worker for å fullføre alle trinnene som er inkludert i dette bygge-a.
6. Eksempel på din egen konfigurasjon
Her er eksempelprosjektarkitekturen som jeg foreslår å implementere via BuildBot
.
Vi vil bruke som et versjonskontrollsystem svn. Selve depotet vil være plassert i en slags sky. Her er adressen til denne skyen . I skyen under svn det er et brukernavn for kontoen: bruker, passwd: passord. Skript som representerer trinn bygge-a vil også være i filialen svn, i en egen mappe buildbot/worker_linux. Disse skriptene er plassert i depotet med den lagrede egenskapen kjørbar.
BuildMaster и Worker kjøre på samme vert prosjekt.vert .BuildMaster lagrer filene i en mappe /hjem/habr/mester. Worker den er lagret i følgende bane /hjem/habr/arbeider. Prosesskommunikasjon BuildMaster-en og Worker-a utføres gjennom port 4000 i henhold til protokollen BuildBot-a, altså 'pb' protokoll.
Målprosjektet er skrevet i sin helhet i Python. Oppgaven er å spore endringene, lage en kjørbar fil, generere dokumentasjon og gjennomføre testing. I tilfelle feil må alle utviklere sende en melding via e-post om at det er en mislykket handling.
Web-visning BuildBot vi vil koble til port 80 for prosjekt.vert. Det er ikke nødvendig å installere Apatch. Som en del av biblioteket tvunnet det er allerede en webserver, BuildBot bruker det.
For å lagre intern informasjon for BuildBot vi vil bruke SQLite.
En vert kreves for utsendelse smtp.ditt.domene - det lar deg sende brev fra post [e-postbeskyttet] uten autentisering. Også på verten 'smtp ' Referatet blir hørt på post 1025.
Det er to personer involvert i prosessen: admin и bruker. admin administrerer BuildBot. bruker er personen som forplikter seg forplikte-s.
Utførbar fil genereres via pyinstaller. Dokumentasjon genereres via oksygen.
For denne arkitekturen 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"
}
Først trenger du BuildMaster-en og Worker-en. Deretter limer du inn denne filen master.cfg в /hjem/habr/mester.
Det neste trinnet er å starte tjenesten BuildMasters
sudo buildbot start /home/habr/master
Start deretter tjenesten Worker-a
buildbot-worker start /home/habr/worker
Klar! Nå Byggebot vil spore endringer og utløse forplikte-y inn svn, utføre trinnene for å bygge og teste et prosjekt med arkitekturen ovenfor.
Nedenfor vil jeg beskrive noen funksjoner ved ovenstående master.cfg.
6.1 På vei til master.cfg
Mens du skriver min master.cfg Mange feil vil bli gjort, så lesing av loggfilen vil være nødvendig. Den lagres som BuildMaster-ec absolutt bane /home/habr/master/twistd.log, og på siden Worker-en med absolutt bane /home/habr/worker/twistd.log. Når du leser feilen og fikser den, må du starte tjenesten på nytt BuildMaster-en. Slik gjøres det:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Arbeide 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, la oss ta en titt på svn_poller. Dette er fortsatt det samme grensesnittet, som regelmessig spørre depotet en gang i minuttet. I dette tilfellet svn_poller bare tilgang til filialen trunk. Mystisk parameter split_file=util.svn.split_file_alwaystrunk setter reglene: hvordan bryte opp mappestrukturen svn på grenene. Han tilbyr dem også relative veier. I sin tur split_file_alwaystrunk forenkler prosessen ved å si at depotet kun inneholder trunk.
В Planleggere angitt Endre filterhvem ser none og forbinder en gren med den trunk ifølge en gitt assosiasjon gjennom split_file_alwaystrunk. Reagerer på endringer i trunk, Lanserer bygger med navn ditt prosjekt.
egenskaper her trengs det slik at admin mottar e-postlister med bygge- og testresultater som eier av prosessen.
Trinn bygge-a kassen i stand til å fullstendig slette alle filer som ligger i den lokale versjonen av depotet Worker-EN. Og så gjør det hele svn oppdatering. Modusen konfigureres gjennom parameteren modus=full, metode=fersk. Parameter haltOnTailure sier at hvis svn oppdatering vil bli utført med en feil, så bør hele prosessen med bygging og testing avbrytes, siden ytterligere handlinger ikke gir mening.
6.3 Brev til deg: reportere har fullmakt til å erklære
journalister er en tjeneste for å sende varsler på 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 sende meldinger .
MailNotifier bruker e-post for å sende varsler.
template_html setter tekstmalen for nyhetsbrevet. HTML brukes til å lage markup. Den er modifisert av motoren (kan sammenlignes med django). BuildBot har et sett med variabler hvis verdier erstattes i malen under prosessen med å generere meldingsteksten. Disse variablene er omsluttet av {{ doble krøllete klammeparenteser }}. For eksempel, sammendrag viser status for fullførte operasjoner, det vil si suksess eller fiasko. EN prosjekter vil gi ut ditt prosjekt. Så, ved å bruke kontrollkommandoer i jinja2, variabler BuildBot-a og python-strengformateringsverktøy, kan du lage en ganske informativ melding.
MailNotifier inneholder følgende argumenter.
fraaddr – adressen som alle vil motta nyhetsbrevet fra.
sendToInterestedUsers=True sender en melding til eieren og brukeren som har laget forplikte.
oppslag — et suffiks som må legges til navnene på brukere som mottar nyhetsbrevet. Så admin hvordan brukeren vil motta nyhetsbrevet på adressen [e-postbeskyttet].
relévert spesifiserer vertsnavnet som serveren åpnes på smtpen smptPort spesifiserer portnummeret som lytter smtp server.
mode="advarsel" sier at utsendelsen kun skal gjøres hvis det er minst ett trinn bygge-a, som endte med statusfeil eller advarsel. I tilfelle suksess er det ikke nødvendig å sende et nyhetsbrev.
ekstramottakere inneholder en liste over personer som forsendelsen skal sendes til i tillegg til eieren og den som har utført forplikte.
meldingsFormatter er et objekt som spesifiserer meldingsformatet, dets mal og et sett med variabler tilgjengelig fra jinja2. Alternativer som f.eks wantProperties=Sant и wantSteps=True definere dette settet med tilgjengelige variabler.
with['services']=[sendMessageToAll] gir en liste over tjenester, blant hvilke våre vil være reporter.
Vi gjorde det! Gratulerer
Vi laget vår egen konfigurasjon og så funksjonaliteten den er i stand til. BuildBot. Dette tror jeg er nok til å forstå om dette verktøyet er nødvendig for å lage prosjektet ditt. Er du interessert i ham? Vil det være nyttig for deg? Er han komfortabel å jobbe med? Da skriver jeg ikke denne artikkelen forgjeves.
Og videre. Jeg vil gjerne at fagmiljøet bruker BuildBot, ble bredere, manualer ble oversatt, og det var enda flere eksempler.
Takk alle sammen for oppmerksomheten. Lykke til.
Kilde: www.habr.com