(Immagine di from
Ciao!
Mi chiamo Evgenij Cherkin, sono un programmatore del team di sviluppo di un'azienda mineraria Polymetal..
Quando si inizia un progetto importante, ci si comincia a chiedere: «Quale software è migliore da utilizzare per la sua gestione?». Un progetto IT attraversa diverse fasi prima di rilasciare una nuova versione. È un vantaggio quando la catena di queste fasi è automatizzata. Il processo di rilascio automatizzato di una nuova versione di un progetto IT si chiama Continuous Integration.. BuildBot si è rivelato un buon aiuto nell'implementare questo processo.
In questo articolo, ho deciso di fornire una panoramica delle funzionalità BuildBot. Cosa può fare questo software? Come avvicinarsi ad esso e come stabilire relazioni di lavoro normali ed EFFICACI? La nostra esperienza può essere applicata anche da voi, creando un servizio di build e test del vostro progetto sulla vostra macchina.
Contenuto
Contenuto
1. Perché BuildBot?
In precedenza su habr-e ho incontrato articoli su implementazioni Continuous Integration. con l'uso di BuildBot. Per esempio, mi è sembrato il più informativo. C'è un altro esempio — . Questi articoli possono essere arricchiti , e facendolo seguire, in lingua inglese. Insieme formano un buon punto di partenza. Dopo aver letto questi articoli, sicuramente vorrete subito fare qualcosa su BuildBot .
Fermati! Qualcuno lo ha usato nei propri progetti? A quanto pare sì, l'hanno utilizzato nei loro compiti. È possibile trovare dell'utilizzo BuildBot anche negli archivi di codici di Google.
Qual è quindi la logica delle persone che usano Buildbot? Ведь есть другие инструменты: CruiseControl e Jenkins. Risponderò così. Per la maggior parte dei compiti Jenkins in effetti sarà sufficiente. D'altra parte, BuildBot è più adattabile, mentre i compiti vengono risolti in modo altrettanto semplice come in Jenkins. A voi la scelta. Ma poiché stiamo cercando uno strumento per un progetto mirato in crescita, perché non scegliere quello che permetterà, partendo da semplici passi, di ottenere un sistema di build interattivo con un'interfaccia unica.
Chi scrive progetti in python si può chiedere: "Perché non scegliere un sistema di integrazione con un'interfaccia chiara in relazione al linguaggio utilizzato nel progetto?". È il momento ideale per presentare i vantaggi. BuildBot.
Quindi, il nostro "quartetto di strumenti". Ho identificato quattro caratteristiche principali. BuildBot:
- È un framework open source sotto licenza GPL.
- Utilizza python come strumento di configurazione e descrizione delle azioni richieste.
- Offre la possibilità di ricevere risposte dalla macchina su cui avviene la compilazione.
- Infine, ha requisiti minimi per l'hosting. Per l'installazione sono richiesti python e twisted, senza necessità di una macchina virtuale o java-machine.
2. Una concezione guidata da BuildMaster
Il fulcro dell'architettura di distribuzione dei compiti è BuildMaster. Esso rappresenta un servizio che:
- monitorizza le modifiche nell'albero sorgente del progetto.
- invia comandi da eseguire al servizio Worker per la costruzione del progetto e i suoi test.
- notifica gli utenti sui risultati delle azioni eseguite.
BuildMaster è configurato tramite un file master.cfg. Questo file si trova nella radice. BuildMaster. Più tardi ti mostrerò come viene creato questo root. Il file stesso master.cfg contiene uno script python che utilizza chiamate BuildBot.
Il prossimo oggetto più importante BuildBot si chiama Worker. Questo servizio può essere eseguito su un altro host con un altro sistema operativo, oppure su quello stesso BuildMaster. Può anche esistere in un ambiente virtuale appositamente preparato con i propri pacchetti e variabili. Questi ambienti virtuali possono essere preparati utilizzando utilità python come virtualenv, venv.
BuildMaster trasmette i comandi a ciascun Worker-u, e quest'ultimo esegue le istruzioni. Quindi, il processo di costruzione e test del progetto può avvenire su Worker-e sotto Windows e su un altro Worker sotto Linux.
Checkout del codice sorgente del progetto avviene su ciascuno Worker-e.
3. Installazione
Quindi, cominciamo. Come host userò Ubuntu 18.04. Su di esso ospiterò un BuildMaster-a e un Worker-a. Ma per prima cosa dobbiamo installare python3.7:
sudo apt-get update
sudo apt-get install python3.7
Per chi ha bisogno di python3.7.2 invece di 3.7.1, è possibile procedere come segue:
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
Il passo successivo è installare Twisted e BuildBot, e pacchetti che permettono di attivare funzionalità aggiuntive 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. Primi passi
È tempo di creare BuildMaster. Sarà nella nostra cartella /home/habr/master.
mkdir master
buildbot create-master master # Qui lo stiamo effettivamente creandoPasso successivo. Creiamo Worker. Sarà nella nostra cartella /home/habr/worker.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Quando avviate Worker, di default creerà nella /home/habr/worker cartella con il nome del progetto specificato in master.cfg. Nella cartella con il nome del progetto verrà creata una directory build, e poi eseguirà checkout. La directory di lavoro per Worker-a sarà /home/habr/yourProject/build.
la directory
E ora, per ciò che ho scritto nel paragrafo precedente: lo script che Master richiederà a Worker-a di eseguire in remoto in questa directory non verrà eseguito, poiché lo script non ha i diritti per l'esecuzione. Per risolvere la situazione, sarà necessario il comando —umask=0o22, che vieta la scrittura in questa directory, ma lascia i diritti di esecuzione. E questo è tutto ciò di cui abbiamo bisogno.
BuildMaster e Worker stabiliscono una connessione tra loro. Talvolta, questa si interrompe e Worker aspetta una risposta da BuildMaster-a. Se non arriva risposta, la connessione viene ripristinata. La chiave —keepalive=60 è esattamente ciò di cui abbiamo bisogno per indicare il tempo dopo il quale connect si riavvia.
5. Configurazione. Ricetta passo passo
Configurazione BuildMaster si svolge sul lato della macchina dove abbiamo eseguito il comando create-master. Nel nostro caso, si tratta della directory /home/habr/master. Il file di configurazione master.cfg non esiste ancora, ma il comando ha già creato il file master.cmg.sample. È necessario rinominarlo in master.cfg.sample in master.cfg
mv master.cfg.sample master.cfgApriamo questo master.cfg. Esamineremo cosa contiene e poi proveremo a creare il nostro file di configurazione.
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 — dizionario base del file di configurazione. Deve essere obbligatoriamente utilizzato nel file di configurazione. Per comodità d'uso, viene introdotto un suo alias nel codice di configurazione «c». Nomi in c[«keyFromDist»] sono elementi fissi per interagire con BuildMaster. Per ogni chiave, come valore viene inserito l'oggetto corrispondente.
5.2 workers
c['workers'] = [worker.Worker("example-worker", "pass")]Questa volta specifichiamo BuildMaster- una lista di Worker-. Noi stessi Worker l'abbiamo creata , specificando you-worker-name e password. Ora dobbiamo sostituirli con example-worker e 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))
In base alla chiave change_source del dizionario c accediamo alla lista in cui è necessario inserire l'oggetto che interroga il repository con il codice sorgente del progetto. Nell'esempio viene utilizzato un repository Git, interrogato a intervalli regolari.
Il primo argomento è il percorso del tuo repository.
workdir rappresenta il percorso della cartella in cui Worker- rispetto al percorso /home/habr/worker/yourProject/build git memorizzerà la versione locale del repository.
branch contiene un ramo specifico nel repository da monitorare.
pollInterval indica il numero di secondi dopo il quale BuildMaster verrà interrogato il repository per rilevare modifiche.
Ci sono diversi metodi per monitorare le modifiche nel repository del progetto.
Il metodo più semplice è Polling, che implica che BuildMaster il server con il repository venga interrogato periodicamente. Nel caso in cui commit ci siano modifiche nel repository, allora BuildMaster creerà un oggetto interno Change e lo invierà al gestore eventi Scheduler, che avvierà il processo di costruzione e testing del progetto su Worker-e. Tra questi passi verrà indicato update il repository. Esattamente su Worker-e verrà creata una copia locale del repository. I dettagli di questo processo saranno svelati nei prossimi due paragrafi ( e ).
Un metodo ancora più elegante per tracciare le modifiche nel repository è la comunicazione diretta dal server in cui è ospitato, a BuildMaster-u riguardo alle modifiche nel codice sorgente del progetto. In questo caso, non appena lo sviluppatore effettua commit, il server del repository del progetto invierà un messaggio a BuildMaster-u. Quest'ultimo, a sua volta, lo intercetterà creando un oggetto PBChangeSource. Poi questo oggetto sarà passato a Scheduler, che attiverà i passaggi per la costruzione del progetto e il suo testing. Una parte importante di questo metodo è lavorare con hook-script del server nel repository. Nello script hook-a, responsabile del trattamento delle azioni durante commit-e, è necessario chiamare l'utility sendchange e specificare l'indirizzo di rete BuildMaster-a. È necessario specificare anche la porta di rete su cui ascolterà PBChangeSource. PBChangeSource, che per inciso, è parte di BuildMaster-a. Questo metodo richiederà i diritti admin-a sul server dove si trova il repository del progetto. Sarà necessario fare prima il backup del repository.
5.4 shedulers
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 – è un elemento che funge da attivatore, avviando l'intera catena di build e test del progetto.
Le modifiche che sono state registrate change_source, sono state elaborate durante l'esecuzione BuildBot-a in un oggetto Change e ora ciascuno Sheduler su cui si basa costruisce richieste per avviare il processo di build del progetto. Tuttavia, determina anche quando trasferire ulteriormente queste richieste in coda. L'oggetto Builder memorizza la coda delle richieste e monitora lo stato dell'attuale build su un Worker-e. Builder esiste sia su BuildMaster-e sia su Worker-e. Esso invia con BuildMaster-a a Worker-a un build — una serie di passaggi da eseguire.
Possiamo vedere che nell'esempio attuale sono stati creati schedulers 2 elementi. Inoltre, ciascuno ha il proprio tipo.
SingleBranchScheduler – una delle classi di programmazione più popolari. Monitora un ramo e si attiva su un cambiamento rilevato in esso. Quando nota delle modifiche, può ritardare l'invio della richiesta di costruzione (ritardare per il periodo indicato in un parametro speciale treeStableTimer). In name viene specificato il nome della programmazione che verrà visualizzato nel BuildBot-web-interfaccia. In ChangeFilter si definisce un filtro, il quale quando le modifiche nel ramo lo rilevano costringe la programmazione a inviare una richiesta di costruzione. In builderNames si specifica il nome builder-a, che definiremo poco dopo. Il nome sarà, nel nostro caso, lo stesso del nome del progetto: yourProject.
ForceScheduler è una cosa piuttosto semplice. Questo tipo di programmazione è attivato con un clic del mouse attraverso BuildBot-web-interfaccia. I parametri hanno lo stesso significato che in SingleBranchScheduler.
P.S. n.° 3. Può tornare utile
Periodic è una programmazione che si attiva con una periodicità fissa nel tempo. La chiamata a essa appare all'incirca così
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 imposta il tempo di questa periodicità in secondi.
BuildFactory crea un specifico build, che poi builder invia a Worker. In BuildFactory sono specificati i passaggi da eseguire Worker-a. I passaggi vengono aggiunti tramite la chiamata al metodo addStep
Il primo passaggio aggiunto in questo esempio è git clean -d -f -f –x, poi git checkout. Queste azioni sono definite nel parametro method, che non è chiaramente specificato, ma implica un valore predefinito fresh. Il parametro mode='incremental' indica che i file nella directory in cui viene effettuato checkout, e quelli assenti nel repository rimangono intatti.
Il secondo passaggio aggiunto è la chiamata a uno script trial con il parametro hello lato Worker-a nella directory /home/habr/worker/yourProject/build con la variabile d'ambiente PYTHONPATH=… In questo modo, puoi scrivere i tuoi script ed eseguirli sul lato Worker-a tramite il passaggio util.ShellCommand. Questi script possono essere inseriti direttamente nel repository. Quindi, durante checkout-a arriveranno in /home/habr/worker/yourProject/build. Tuttavia, ci sono due "ma":
- Worker deve essere creato con la chiave in modo che non blocchi i diritti di esecuzione dopo checkout-a.
- Durante git pushPer questi script è necessario specificare la proprietà eseguibile, per poi checkoutnon perdere i diritti di esecuzione dello script Git.
5.6 builders
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Di cosa si tratta Builder è stato spiegato . Ora spiegherò in dettaglio come crearne uno. BuilderConfig è un costruttore builder. Si possono avere diversi costruttori in c[‘builders’] poiché è una lista di oggetti builder di questo tipo. Ora riscriveremo leggermente l'esempio, avvicinandolo al nostro obiettivo. BuildBotc['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory))
Adesso parlerò dei parametri
che definisce il nome BuilderConfig.
name -a. Qui lo abbiamo chiamato builder. Ciò significa che su yourProject-e verrà creato proprio quel percorso Workerche viene trovato /home/habr/worker/yourProject/build. Sheduler proprio con questo nome. builder workernames
contiene una lista -o. Ognuno dei quali deve essere aggiunto a Workerc[‘workers’] factory.
è specifico , associato a build. Invierà un oggetto builderper eseguire tutti i passaggi inclusi in questa build con Worker Ecco l'architettura dell'esempio di progetto che propongo di realizzare attraverso build-a.
6. Esempio di una configurazione personalizzata
Utilizzeremo BuildBot
.
svn svn. Il repository si troverà in un certo cloud. Ecco l'indirizzo di questo cloud . Nel cloud c'è un'account username: svn , passwd: utente. Gli script, che rappresentano i passaggi password-a saranno anch'essi nella branch build, in una cartella separata svnbuildbot/worker_linux . Questi script sono nel repository con l'attributo salvatoexecutable funzionano su un host comune.
BuildMaster e Worker project.host conserva i suoi file nella cartella .BuildMaster conserva anche nel seguente percorso /home/habr/master. Worker . La comunicazione tra i processi /home/habr/worker-a e BuildMaster-a avviene attraverso la porta 4000 utilizzando il protocollo Worker-a, cioè BuildBot‘pb’ protocollo. Il progetto target è completamente scritto in Python. L'obiettivo è monitorarne le modifiche, creare un file executable, generare documentazione e condurre test. In caso di failure, è necessario inviare un'email a tutti gli sviluppatori informandoli che si è verificato un errore.
Web display
lo collegheremo sulla porta 80 per BuildBot . Non è necessario installare Apache. Nella libreria conserva i suoi file nella cartellatwisted è già presente un server web, che utilizza. BuildBot Per la memorizzazione delle informazioni interne per
Per l'invio di email è necessaria un'host BuildBot useremo sqlite.
smtp.your.domain – qui è consentito inviare email da projectHost@your.domain senza autenticazione. Inoltre, sull'host ‘ smtp‘ il protocollo ascolta sulla porta 1025. ‘ il protocollo è in ascolto sulla porta 1025.
Le persone coinvolte nel processo sono due: admin e utente. admin amministra BuildBot. user è la persona che esegue commit-i.
Il file eseguibile viene generato tramite pyinstaller. La documentazione viene generata tramite doxygen.
Per questa architettura ho scritto quanto segue 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>Stato della build: {{ summary }}</h4>
<p>Servizio utilizzato per la build: {{ workername }}</p>
<p>Progetto: {{ projects }}</p>
<p>Per visualizzare l'interfaccia di gestione, fare riferimento al seguente link: {{ buildbot_url }}</p>
<p>Per vedere il risultato della build, cliccare sul seguente link: {{ build_url }}</p>
<p>Utilizzando WinSCP, si può connettersi al server con ip:xxx.xx.xxx.xx. Accedendo con habr/password, è possibile recuperare il file eseguibile dalla directory ~/worker/yourProject/build/dist.</p>
<p><b>La build è stata eseguita tramite 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'] = "Il processo di costruzione"
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"
}
Per iniziare è necessario BuildMaster-a avviene attraverso la porta 4000 utilizzando il protocollo Worker-a. Quindi inserire questo file master.cfg in /home/habr/master.
Il passo successivo richiede di avviare il servizio BuildMaster-a
sudo buildbot start /home/habr/master
Quindi avviare il servizio Worker-a
buildbot-worker start /home/habr/worker
Fatto! Ora Buildbot monitorerà le modifiche e verrà attivato da commit-u in svn, eseguendo i passaggi di costruzione e test del progetto con l'architettura sopra citata.
Di seguito descriverò alcune caratteristiche di cui sopra master.cfg.
6.1 Sulla strada per il proprio master.cfg
Durante la scrittura del mio master.cfg si commetteranno molti errori, quindi sarà necessario consultare il file di log. È conservato sia su BuildMaster-e c con percorso assoluto /home/habr/master/twistd.log, sia sul lato Worker-a con percorso assoluto /home/habr/worker/twistd.log. Man mano che si leggono gli errori e si risolvono, sarà necessario riavviare il servizio BuildMaster-a. Ecco come si fa:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Lavorare con 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)
Iniziamo dando un'occhiata a svn_poller. Si tratta dello stesso interfaccia che interroga regolarmente il repository ogni minuto. In questo caso svn_poller si riferisce solo al ramo trunk. Il misterioso parametro split_file=util.svn.split_file_alwaystrunk stabilisce le regole per: come suddividere la struttura delle cartelle svn in rami. Stabilisce anche percorsi relativi. A sua volta split_file_alwaystrunk semplifica il processo, specificando che nel repository ci sono solo trunk.
In Schedulers che si indica ChangeFilter, che vede Nessuno e associa a esso il ramo trunk secondo l'associazione definita tramite split_file_alwaystrunk. Rispondendo alle modifiche in trunk, avvia builder c con nome yourProject.
properties questo è necessario affinché l'amministratore riceva aggiornamenti sui risultati della compilazione e dei test come proprietario del processo.
Passo build-a checkout è in grado di eseguire la rimozione completa di tutti i file presenti nella versione locale del repository Worker-e quindi eseguire completo svn update. La modalità è configurata tramite il parametro mode=full, method=fresh. Il parametro haltOnTailure indica che se svn update viene eseguito con errore, l'intero processo di compilazione e test dovrebbe essere interrotto, poiché le ulteriori azioni non hanno senso.
6.3 Riceverai una mail: i reporter sono autorizzati a dichiarare
reporters è il servizio di invio notifiche via email.
template_html=u'''
<h4>Stato della build: {{ summary }}</h4>
<p>Servizio utilizzato per la build: {{ workername }}</p>
<p>Progetto: {{ projects }}</p>
<p>Per visualizzare l'interfaccia di gestione, fare riferimento al seguente link: {{ buildbot_url }}</p>
<p>Per vedere il risultato della build, cliccare sul seguente link: {{ build_url }}</p>
<p>Utilizzando WinSCP, si può connettersi al server con ip:xxx.xx.xxx.xx. Accedendo con habr/password, è possibile recuperare il file eseguibile dalla directory ~/worker/yourProject/build/dist.</p>
<p><b>La build è stata eseguita tramite 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]
Può inviare messaggi .
MailNotifier utilizza la posta per inviare notifiche.
template_html definisce il modello del testo per l'invio. Per creare la formattazione viene utilizzato l'html. È modificato dal motore (può essere paragonato a django). BuildBot ha un insieme di variabili, i cui valori vengono inseriti nel modello durante la formazione del testo del messaggio. Queste variabili sono racchiuse tra {{ doppie parentesi graffe }}. Ad esempio, summary stampa lo stato delle operazioni eseguite, cioè success o failure. E projects stamperà yourProject. Così, utilizzando i comandi di gestione in jinja2, le variabili BuildBot-a e i mezzi di formattazione delle stringhe Python possono creare un messaggio informativo.
MailNotifier contiene i seguenti argomenti.
fromaddr – l'indirizzo da cui verrà inviata la newsletter.
sendToInterestedUsers=True invia il messaggio sia al proprietario che all'utente che ha effettuato commit.
lookup – il suffisso da aggiungere ai nomi degli utenti che ricevono la newsletter. Così admin l'utente riceverà la newsletter all'indirizzo admin@your.domain.
relayhost definisce il nome host sul quale è aperto il server ‘ il protocollo ascolta sulla porta 1025., a smptPort definisce il numero della porta che ascolta ‘ il protocollo ascolta sulla porta 1025. server.
mode=«warning» indica che la newsletter deve essere inviata solo se c'è almeno un passo build-a che è terminato con stato di failure o warning. In caso di success non è necessaria l'invio della newsletter.
extraRecipients contiene un elenco di persone a cui inviare la newsletter oltre al proprietario e alla persona che ha effettuato commit.
messageFormatter è un oggetto che definisce il formato del messaggio, il suo modello e il set di variabili disponibili da jinja2. Parametri come wantProperties=True e wantSteps=True definiscono questo set di variabili disponibili.
s['services']=[sendMessageToAll] fornisce un elenco di servizi, tra cui il nostro reporter.
Ce l'abbiamo fatta! Congratulazioni!
Abbiamo creato una configurazione personalizzata e abbiamo visto le funzionalità disponibili. BuildBotQuesto, penso, è sufficiente per capire se questo strumento è utile per il tuo progetto. Ti interessa? Ti sarà utile? È facile da usare? Allora non ho scritto questo articolo invano.
Inoltre, mi piacerebbe che la comunità professionale che utilizza BuildBotdiventasse più ampia, con manuali tradotti e sempre più esempi.
Grazie a tutti per l'attenzione. Buona fortuna.
Fonte: habr.com
