(Imaxe de de
Ola!
meu nome Evgeniy Cherkin, Son programador nun equipo de desenvolvemento dunha empresa mineira Polimetal.
Cando comeza un proxecto grande, comeza a pensar: "Que software é mellor usar para atenderlle?" Un proxecto de TI pasa por varias etapas antes de lanzar a seguinte versión. É bo cando se automatiza a cadea destas etapas. Chámase o proceso automatizado de lanzar unha nova versión dun proxecto de TI Integración continua. BuildBot resultou ser un bo asistente para nós na implementación deste proceso.
Neste artigo decidín ofrecer unha visión xeral das posibilidades BuildBot. De que é capaz este software? Como achegarse a el e como construír con el unha RELACIÓN DE TRABALLO EFECTIVA normal? Pode aplicar a nosa experiencia vostede mesmo creando un servizo de traballo para construír e probar o seu proxecto na súa máquina.
Contido
Contido
1. Por que BuildBot?
Anteriormente en habr-e atopeime con artigos sobre a implementación Integración continua usando BuildBot... Por exemplo, Pareceume o máis informativo. Hai outro exemplo - . Estes artigos poden ser condimentados E despois diso, en inglés. O coupé é un bo punto de partida. Despois de ler estes artigos, probablemente quererás algo BuildBot facer.
Pare! Alguén o usou realmente nos seus proxectos? Resulta que si aplicárono nas súas tarefas. Pódese atopar de uso BuildBot e nos arquivos de códigos de Google.
Entón, cal é a lóxica das persoas que usan Buildbot? Despois de todo, hai outras ferramentas: Control de cruceiro и Jenkins. Vou responder deste xeito. Para a maioría das tarefas Jenkins e a verdade será suficiente. Á súa vez, BuildBot - máis adaptativo, mentres que os problemas se resolven alí de forma sinxela como en Jenkins. A elección é túa. Pero xa que buscamos unha ferramenta para un proxecto obxectivo en desenvolvemento, por que non escoller unha que permita, partindo de simples pasos, obter un sistema de compilación que teña interactividade e unha interface única.
Para aqueles cuxo proxecto de destino está escrito en python, xorde a pregunta: "Por que non escoller un sistema de integración que teña unha interface clara en canto á linguaxe utilizada no proxecto?" E agora toca presentar os beneficios BuildBot.
Así, o noso “cuarteto instrumental”. Para min, identifiquei catro características BuildBot:
- É un framework de código aberto baixo licenza GPL
- Este é o uso de Python como ferramenta de configuración e descrición das accións necesarias
- Esta é unha oportunidade para recibir unha resposta da máquina na que se realiza a montaxe
- Estes son, finalmente, os requisitos mínimos para un Host. A implantación require python e twisted, e non require unha máquina virtual nin unha máquina java.
2. Concepto liderado por BuildMaster
O elemento central da arquitectura de distribución de tarefas é BuildMaster. É un servizo que:
- fai un seguimento cambios na árbore de orixe do proxecto
- envía comandos que debe ser executado polo servizo Worker para construír o proxecto e probalo
- notifica usuarios sobre os resultados das accións realizadas
BuildMaster configurado mediante ficheiro mestre.cfg. Este ficheiro está na raíz BuildMaster. Máis tarde mostrarei como se crea esta raíz. O propio ficheiro mestre.cfg contén un script Python que usa chamadas BuildBot.
O seguinte obxecto máis importante BuildBot Ten un nome Traballador. Este servizo pódese iniciar noutro host cun sistema operativo diferente, ou quizais no que se atopa BuildMaster. Tamén pode existir nun entorno virtual especialmente preparado cos seus propios paquetes e variables. Estes ambientes virtuais pódense preparar usando utilidades de Python como virtualenv, venv.
BuildMaster emite comandos a todos Traballador-y, e el, á súa vez, cumpre. É dicir, resulta que o proceso de construción e proba dun proxecto pode continuar Traballador-e con Windows e noutro Worker con Linux.
Comprobar códigos fonte do proxecto ocorre en cada un Traballador-e.
3. Instalación
Entón, imos. Vou usar Ubuntu 18.04 como host. Poñerei un BuildMaster-a e unha Traballador-a. Pero primeiro necesitas instalar python3.7:
sudo apt-get update
sudo apt-get install python3.7
Para aqueles que necesiten python3.7.2 en lugar de 3.7.1, podes facer o seguinte:
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
O seguinte paso é instalar Tuiteado и BuildBot, así como paquetes que che permiten utilizar funcionalidades adicionais BuildBot-O.
/*Все что под 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. Primeiros pasos
Tempo de crear BuildMaster. Estará no noso cartafol /home/habr/master.
mkdir master
buildbot create-master master # Собственно сдесь и создаемSeguinte paso. Imos crear Traballador. Estará no noso cartafol /home/habr/traballador.
mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password
Cando corres Traballador, entón por defecto crearase en /home/habr/traballador cartafol co nome do proxecto, que se especifica en mestre.cfg. E no cartafol co nome do proxecto crearase un directorio construír, e seguirá facéndoo checkout. Directorio de traballo para Traballador-e converterase nun directorio /home/habr/yourProject/build.
"Chave de ouro
E agora para o que escribín o parágrafo anterior: un guión que Mestre demandará de Traballador-e feito de forma remota neste directorio non se executará porque o script non ten permisos para executarse. Para corrixir a situación, necesitará unha chave --umask=0o22, que prohibe escribir neste directorio, pero conservará os dereitos de inicio. E iso é todo o que necesitamos.
BuildMaster и Traballador establecer unha conexión entre si. Ocorre que se rompe e Traballador agardando por algún tempo unha resposta de BuildMaster-A. Se non hai resposta, reiniciarase a conexión. Chave --keepalive=60 só precisaba indicar o tempo despois do cal conectarse reinicia.
5. Configuración. Receita paso a paso
Configuración BuildMaster realízase no lado da máquina onde executamos o comando crear-mestre. No noso caso, este é un directorio /home/habr/master. Ficheiro de configuración mestre.cfg aínda non existe, pero o propio comando xa creou o ficheiro mestre.cmg.mostra. Debes renomealo a mestre.cfg.mostra в mestre.cfg
mv master.cfg.sample master.cfgImos abrir este mestre.cfg. E vexamos en que consiste. E despois diso, imos tentar facer o noso propio ficheiro de configuración.
mestre.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 — dicionario básico do ficheiro de configuración. Debe incluírse no ficheiro de configuración. Para facilitar o seu uso, introdúcese un alias no código de configuración "c". Títulos в c["keyFromDist"] son elementos fixos para a interacción BuildMaster. Para cada chave, substitúese o obxecto correspondente como valor.
traballadores 5.2
c['workers'] = [worker.Worker("example-worker", "pass")]Nesta ocasión indicamos BuildMaster-y lista de Traballador-s. Eu mesmo Traballador creamos , indicando nome-traballador и contrasinal. Agora deben especificarse no seu lugar exemplo-traballador и pasar .
5.3 cambiar_fonte
c['change_source'] = []
c['change_source'].append(changes.GitPoller(
'git://github.com/buildbot/hello-world.git',
workdir='gitpoller-workdir', branch='master',
pollInterval=300))
Por chave fonte_cambio dicionario c accedemos á lista onde queremos poñer un obxecto que consulta o repositorio co código fonte do proxecto. O exemplo usa un repositorio de Git que se consulta a determinados intervalos.
O primeiro argumento é o camiño ao teu repositorio.
workdir representa o camiño ao cartafol onde está ao lado Traballador-a relativa ao camiño /home/habr/worker/yourProject/build git almacenará a versión local do repositorio.
sector contén unha rama específica no repositorio que se debe seguir.
Intervalo de votación contén o número de segundos despois dos cales BuildMaster sondeará o repositorio para ver os cambios.
Existen varios métodos para rastrexar os cambios no repositorio dun proxecto.
O método máis sinxelo é Interrogación, o que implica que BuildMaster consulta periodicamente o servidor co repositorio. Se comprometerse reflectiu os cambios no repositorio, entón BuildMaster creará un obxecto interno con certo atraso Cambiar e envíao ao controlador de eventos Programador, que poñerá en marcha os pasos para construír e probar o proxecto Traballador-e. Entre estes pasos indicaranse actualizar repositorio. Exactamente encendido TraballadorIsto creará unha copia local do repositorio. Os detalles deste proceso cubriranse a continuación nas dúas seguintes seccións. ( и ).
Un método aínda máis elegante para rastrexar os cambios nun repositorio é enviar mensaxes directamente desde o servidor ao que o aloxa BuildMaster- sobre a modificación dos códigos fonte do proxecto. Neste caso, tan pronto como o desenvolvedor fai comprometerse, o servidor co repositorio do proxecto enviará unha mensaxe BuildMaster- e. E el, á súa vez, interceptarao creando un obxecto PBCchangeSource. A continuación, este obxecto será transferido a Programador, que activa os pasos para construír o proxecto e probalo. Unha parte importante deste método é traballar gancho-scripts do servidor no repositorio. No guión gancho-a, responsable da tramitación das actuacións cando comprometerse-e, cómpre chamar á utilidade enviar cambio e especifique o enderezo da rede BuildMaster-A. Tamén cómpre especificar o porto de rede que escoitará PBCchangeSource. PBCchangeSource, por certo, forma parte BuildMaster-A. Este método requirirá permiso administrador-a no servidor onde se atopa o repositorio do proxecto. Primeiro terás que facer unha copia de seguridade do repositorio.
5.4 Programadores
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"]))
programadores – este é un elemento que actúa como detonante que inicia toda a cadea de montaxe e proba do proxecto.
Aqueles cambios que se rexistraron fonte_cambio, transformado no proceso de traballo BuildBot-a opoñerse Cambiar e agora todos Programador baseándose neles, constrúe solicitudes para iniciar o proceso de construción do proxecto. Non obstante, tamén determina cando estas solicitudes se transfiren máis á cola. Un obxecto Constructor almacena unha cola de solicitudes e fai un seguimento do estado da asemblea actual nun separado Traballador-e. Constructor existe en BuildMaster-e e así Traballador-e. Envía con BuildMaster-a on Traballador-e xa específico construír - unha serie de pasos que se deben seguir.
Vemos que no exemplo actual tal programadores Créanse 2 pezas. Ademais, cada un ten o seu propio tipo.
SingleBranchScheduler – unha das clases máis populares do horario. Observa unha rama e desenvólvese por un cambio rexistrado nela. Cando ve cambios, pode atrasar o envío da solicitude de compilación (aplazar o período especificado no parámetro especial treeStableTimer). EN nome establece o nome da programación na que se mostrará BuildBot- interface web. EN Cambiar filtro establécese un filtro, despois de pasar que cambios na rama solicitan a programación para enviar unha solicitude de construción. EN builderNames indícase o nome constructor-a, que fixaremos un pouco máis adiante. O nome no noso caso será o mesmo que o nome do proxecto: o teuProxecto.
ForceScheduler unha cousa moi sinxela. Este tipo de programación desenvólvese mediante un clic do rato BuildBot- interface web. Os parámetros teñen a mesma esencia que en SingleBranchScheduler.
PS nº 3. Quizais sexa útil
Periódico é un horario que se executa nunha determinada frecuencia fixada nun tempo. A chamada parece algo así
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 especifica o tempo desta periodicidade en segundos.
BuildFactory crea un específico construír, que entón constructor envía a Traballador. En BuildFactory indica os pasos a seguir Traballador- e. Os pasos engádense chamando ao método addStep
O primeiro paso engadido neste exemplo é git clean -d -f -f –x, entón git checkout. Estas accións están incluídas no parámetro método, que non está claramente indicado pero implica un valor predeterminado fresco... Parámetro modo='incremental' indica que os ficheiros son do directorio onde se atopa chechout, aínda que non aparece no repositorio, permanecen intactos.
O segundo paso engadido é chamar ao script xuízo con parámetro Ola no lado Traballador-a do directorio /home/habr/worker/yourProject/build coa variable de ambiente PATHONPATH=... Así, pode escribir os seus propios scripts e executalos no lateral Traballador-a cada paso util.ShellCommand. Estes scripts pódense colocar directamente no repositorio. Despois ás chechout-e caerán /home/habr/worker/yourProject/build. Non obstante, hai dous "peros":
- Traballador debe crearse cunha chave para que non bloquee os dereitos de execución despois checkout-O.
- En git push-e destes scripts precisa especificar a propiedade exacutablespara que despois chechout-e non perdeu o dereito a executar o script Git.
5.6 construtores
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
Sobre o que é Constructor dixo . Agora falarei con máis detalle sobre como crealo. BuilderConfig é un construtor constructor. Tales deseñadores en c['construtores'] podes especificar varios, xa que esta é unha folla de obxectos constructor tipo. Agora imos reescribir o exemplo de BuildBot, achegándoo á nosa tarefa.
c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
workernames=["yourWorkerName"],
factory=factory))
Agora falarei sobre os parámetros BuilderConfig.
nome especifica o nome constructor-a. Aquí puxemos o nome o teuProxecto... Isto significa que on Traballador- Crearase este mesmo camiño /home/habr/worker/yourProject/build. Programador Buscar constructor só con este nome.
nomes de traballo contén folla Traballador-s. Cada un dos cales hai que engadir c['traballadores'].
fábrica - específico construír, coa que está asociada constructor. El enviará o obxecto construír en Traballador para completar todos os pasos incluídos neste construír-O.
6. Exemplo de configuración propia
Aquí está o exemplo de arquitectura do proxecto que propoño implementar mediante BuildBot
.
Usaremos como sistema de control de versións svn. O propio repositorio estará situado nalgún tipo de nube. Aquí está o enderezo desta nube . Na nube debaixo svn hai un nome de usuario da conta: usuario, passwd: contrasinal. Guións que representan pasos construír-a tamén estará no filial svn, nun cartafol separado buildbot/worker_linux. Estes scripts están situados no repositorio coa propiedade gardada executable.
BuildMaster и Traballador executar no mesmo host proxecto.host .BuildMaster almacena os seus ficheiros nun cartafol /home/habr/master. Traballador gárdase no seguinte camiño /home/habr/traballador. Proceso de comunicación BuildMaster-a e Traballador-a realízase a través do porto 4000 segundo o protocolo BuildBot-a, é dicir 'pb' protocolo.
O proxecto de destino está escrito enteiramente en Python. A tarefa é rastrexar os seus cambios, crear un ficheiro executable, xerar documentación e realizar probas. En caso de falla, todos os desenvolvedores deben enviar unha mensaxe por correo electrónico indicando que hai unha acción sen éxito.
Visualización web BuildBot conectarémonos ao porto 80 para proxecto.host. Non é necesario instalar Apatch. Como parte da biblioteca retorcido xa hai un servidor web, BuildBot úsao.
Para almacenar información interna para BuildBot empregaremos sqlite.
Requírese un host para enviar correo smtp.o teu.dominio - permite enviar cartas desde o correo [protexido por correo electrónico] sen autenticación. Tamén no host'SMTP ' A acta está a escoitarse no posto 1025.
Hai dúas persoas implicadas no proceso: administrador и usuario. administrador administra BuildBot. o usuario é a persoa que se compromete comprometerse-s.
O ficheiro executable xérase mediante pyinstaller. A documentación é xerada a través de doxíxeno.
Para esta arquitectura escribín isto: mestre.cfg:
mestre.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"
}
Primeiro necesitas BuildMaster-a e Traballador-a. A continuación, pega este ficheiro mestre.cfg в /home/habr/master.
O seguinte paso é iniciar o servizo BuildMaster-e
sudo buildbot start /home/habr/master
A continuación, inicie o servizo Traballador-a
buildbot-worker start /home/habr/worker
Listo! Agora Buildbot fará un seguimento dos cambios e desencadeará comprometerse- e en svn, realizando os pasos de construción e proba dun proxecto coa arquitectura anterior.
A continuación describirei algunhas características do anterior mestre.cfg.
6.1 De camiño ao teu mestre.cfg
Mentres escribía o meu mestre.cfg Cometeranse moitos erros, polo que será necesario ler o ficheiro de rexistro. Gárdase como BuildMaster-ec camiño absoluto /home/habr/master/twistd.log, e ao lado Traballador-a con camiño absoluto /home/habr/worker/twistd.log. Ao ler o erro e solucionalo, terás que reiniciar o servizo BuildMaster-a. Velaquí como se fai:
sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master
6.2 Traballar 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)
En primeiro lugar, imos botarlle unha ollada svn_poller. Esta aínda é a mesma interface, consultando regularmente o repositorio unha vez por minuto. Neste caso svn_poller só accede á sucursal tronco. Parámetro misterioso split_file=util.svn.split_file_alwaystrunk establece as regras: como dividir a estrutura do cartafol svn nas pólas. Tamén lles ofrece camiños relativos. Á súa vez split_file_alwaystrunk simplifica o proceso dicindo que o repositorio só contén tronco.
В Programadores indicado Cambiar filtroquen ve ningún e asocia unha rama con ela tronco segundo unha determinada asociación a través split_file_alwaystrunk. Respondendo aos cambios en tronco, Lanzamentos constructor con nome o teuProxecto.
Propiedades aquí é necesario para que o administrador reciba listas de correo de resultados de compilación e probas como propietario do proceso.
Paso construír-a checkout capaz de eliminar completamente calquera ficheiro situado na versión local do repositorio Traballador-A. E despois fai o completo actualización svn. O modo configúrase mediante o parámetro modo=cheo, método=fresco... Parámetro haltOnTailure di que se actualización svn executarase cun erro, entón todo o proceso de construción e proba debe suspenderse, xa que as accións posteriores non teñen sentido.
6.3 Carta para vostede: os xornalistas están autorizados a declarar
reporteiros é un servizo para enviar notificacións por correo electrónico.
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]
Pode enviar mensaxes .
MailNotifier usa o correo electrónico para enviar notificacións.
template_html establece o modelo de texto para o boletín. O HTML úsase para crear marcas. É modificado polo motor (pódese comparar con django). BuildBot ten un conxunto de variables cuxos valores son substituídos no modelo durante o proceso de xeración do texto da mensaxe. Estas variables están encerradas entre {{ chaves dobres }}. Por exemplo, resumo mostra o estado das operacións completadas, é dicir, éxito ou fracaso. A proxectos sairá o teuProxecto. Entón, usando comandos de control en jinja2, variables BuildBot-a e ferramentas de formato de cadea Python, pode crear unha mensaxe bastante informativa.
MailNotifier contén os seguintes argumentos.
dendeaddr – o enderezo desde o que todos recibirán o boletín.
enviar a usuarios interesados=True envía unha mensaxe ao propietario e usuario que fixo comprometerse.
Buscar — un sufixo que se debe engadir aos nomes dos usuarios que reciben o boletín. Entón administrador como recibirá o usuario o boletín no enderezo [protexido por correo electrónico].
anfitrión de retransmisión especifica o nome de host no que se abre o servidor SMTP, A smptPort especifica o número de porto que escoita SMTP servidor.
modo = "aviso" di que o envío só se debe facer se hai polo menos un paso construír-a, que rematou coa falla de estado ou aviso. En caso de éxito, non é necesario enviar un boletín.
Destinatarios extra contén unha lista de persoas ás que se debe enviar o envío, ademais do propietario e a persoa que realizou o envío comprometerse.
formato de mensaxes é un obxecto que especifica o formato da mensaxe, o seu modelo e un conxunto de variables dispoñibles desde jinja2. Opcións como wantProperties=Verdadero и wantSteps=Verdade definir este conxunto de variables dispoñibles.
with['services']=[sendMessageToAll] ofrece unha relación de servizos, entre os que estará o noso xornalista.
Fixémolo! Parabéns
Creamos a nosa propia configuración e vimos a funcionalidade das que é capaz. BuildBot. Isto, creo, é suficiente para entender se esta ferramenta é necesaria para crear o teu proxecto. Estás interesado nel? Será útil para ti? É cómodo traballar con el? Entón non estou escribindo este artigo en balde.
E máis aló. Gustaríame que a comunidade profesional use BuildBot, fíxose máis amplo, traducíronse manuais e aínda houbo máis exemplos.
Grazas a todos pola vosa atención. Moita sorte.
Fonte: www.habr.com