Um exemplo de implementação de integração contínua usando BuildBot

Um exemplo de implementação de integração contínua usando BuildBot
(Imagem de Computadorizador da pixabay)

Oi!

O meu nome é Evgeniy Cherkin, sou programador na equipe de desenvolvimento de uma empresa de mineração Polimetal.

Ao iniciar qualquer projeto grande, você começa a pensar: “Qual software é melhor usar para atendê-lo?” Um projeto de TI passa por vários estágios antes de lançar a próxima versão. É bom quando a cadeia dessas etapas é automatizada. O processo automatizado de lançamento de uma nova versão de um projeto de TI é chamado Integração contínua. BuildBotName acabou por ser um bom assistente para nós na implementação deste processo.

Neste artigo decidi fornecer uma visão geral das possibilidades BuildBotName. Do que este software é capaz? Como abordá-lo e como construir um RELACIONAMENTO DE TRABALHO EFICAZ normal com ele? Você mesmo pode aplicar nossa experiência criando um serviço funcional para construir e testar seu projeto em sua máquina.

Conteúdo

Conteúdo

1. Por que BuildBot?
2. Conceito liderado por BuildMaster
3. Instalação
4. Primeiros passos

5. Configuração. Receita passo a passo

5.1 BuildmasterConfig
Trabalhadores 5.2
5.3 mudança_fonte
5.4 agendadores

5.5 Construir Fábrica
5.6 construtores

6. Exemplo de sua própria configuração

6.1 A caminho do seu master.cfg
6.2 Trabalhando com SVN
6.3 Carta para você: os repórteres estão autorizados a declarar

Conseguimos! Parabéns

1. Por que BuildBot?

Anteriormente, no habr-e, encontrei artigos sobre implementação Integração contínua usando BuildBotName. Por exemplo, esse aqui Achei o mais informativo. Há outro exemplo - mais simples. Esses artigos podem ser temperados exemplo do manualE это depois disso, em inglês. O cupê é um bom ponto de partida. Depois de ler esses artigos, você provavelmente desejará imediatamente algo BuildBotName fazer.

Parar! Alguém realmente usou isso em seus projetos? Acontece que sim muitos aplicaram-no em suas tarefas. Pode ser encontrado exemplos usar BuildBotName e nos arquivos de código do Google.

Então, qual é a lógica das pessoas que usam Construir bot? Afinal, existem outras ferramentas: Controle de Cruzeiro и Jenkins. Eu responderei desta forma. Para a maioria das tarefas Jenkins e a verdade será suficiente. Por sua vez, BuildBotName - mais adaptativo, enquanto os problemas são resolvidos tão simplesmente como em Jenkins. A escolha é sua. Mas como procuramos uma ferramenta para um projeto alvo em desenvolvimento, porque não escolher uma que permita, a partir de passos simples, obter um sistema de construção que tenha interatividade e uma interface única.

Para aqueles cujo projeto alvo é escrito em python, surge a pergunta: “Por que não escolher um sistema de integração que tenha uma interface clara em termos da linguagem utilizada no projeto?” E agora é hora de apresentar os benefícios BuildBotName.

Então, nosso “quarteto instrumental”. Para mim, identifiquei quatro características BuildBotName:

  1. É uma estrutura de código aberto sob licença GPL
  2. Este é o uso de python como ferramenta de configuração e descrição das ações necessárias
  3. Esta é uma oportunidade de receber uma resposta da máquina na qual a montagem ocorre
  4. Estes são, finalmente, os requisitos mínimos para um Host. A implantação requer python e twisted e não requer uma máquina virtual e uma máquina java.

2. Conceito liderado por BuildMaster

Um exemplo de implementação de integração contínua usando BuildBot

Central para a arquitetura de distribuição de tarefas é Construir Mestre. É um serviço que:

  • mantém o controle mudanças na árvore de origem do projeto
  • envia comandos que devem ser executados pelo serviço Worker para construir o projeto e testá-lo
  • notifica usuários sobre os resultados das ações tomadas

Construir Mestre configurado via arquivo mestre.cfg. Este arquivo está na raiz Construir Mestre. Mais tarde mostrarei como essa raiz é criada. O arquivo em si mestre.cfg contém um script python que usa chamadas BuildBotName.

Próximo objeto mais importante BuildBotName Tem o nome Trabalhador. Este serviço pode ser lançado em outro host com um sistema operacional diferente, ou talvez naquele onde Construir Mestre. Também pode existir em um ambiente virtual especialmente preparado com seus próprios pacotes e variáveis. Esses ambientes virtuais podem ser preparados usando utilitários python como virtualenv, venv.

Construir Mestre transmite comandos para todos Trabalhador-y, e ele, por sua vez, os cumpre. Ou seja, acontece que o processo de construção e teste de um projeto pode continuar Trabalhador-e executando Windows e em outro Worker executando Linux.

Confira códigos-fonte do projeto ocorre em cada TrabalhadorEh.

3. Instalação

Então vamos. Usarei o Ubuntu 18.04 como host. vou colocar um nele Construir Mestre-um e um Trabalhador-a. Mas primeiro você precisa instalar o python3.7:

sudo apt-get update
sudo apt-get install python3.7

Para quem precisa do python3.7.2 em vez do 3.7.1, você pode fazer 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 próximo passo é instalar Tweetado и BuildBotName, bem como pacotes que permitem usar funcionalidades adicionais BuildBotName-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. Primeiros passos

Hora de criar Construir Mestre. Estará em nossa pasta /home/habr/master.

mkdir master
buildbot create-master master # Собственно сдесь и создаем

Próxima Etapa. Vamos criar Trabalhador. Estará em nossa pasta /home/habr/trabalhador.

mkdir worker
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password

Quando você corre Trabalhador, então, por padrão, ele criará em /home/habr/trabalhador pasta com o nome do projeto, que é especificado em mestre.cfg. E na pasta com o nome do projeto irá criar um diretório construir, e continuará fazendo isso checkout. Diretório de trabalho para Trabalhador-e se tornará um diretório /home/habr/seuProjeto/build.

"Chave de ouro
E agora o que escrevi no parágrafo anterior: um roteiro que Mestre exigirá de Trabalhador-e feito remotamente neste diretório não será executado porque o script não tem permissão para ser executado. Para corrigir a situação, você precisará de uma chave --umask=0o22, que proíbe a gravação neste diretório, mas manterá os direitos de inicialização. E isso é tudo que precisamos.

Construir Mestre и Trabalhador estabelecer uma conexão entre si. Acontece que ele quebra e Trabalhador esperando algum tempo por uma resposta de Construir Mestre-A. Se não houver resposta, a conexão será reiniciada. Chave --keepalive=60 só precisava indicar o tempo após o qual connect reinicia.

5. Configuração. Receita passo a passo

Configuração Construir Mestre é realizado na lateral da máquina onde executamos o comando criar mestre. No nosso caso, este é um diretório /home/habr/master. Arquivo de configuração mestre.cfg ainda não existe, mas o próprio comando já criou o arquivo mestre.cmg.amostra. Você precisa renomeá-lo para master.cfg.sample в mestre.cfg

mv master.cfg.sample master.cfg

Vamos abrir este mestre.cfg. E vamos ver em que consiste. E depois disso, vamos tentar fazer nosso próprio arquivo de configuração.

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 — dicionário básico do arquivo de configuração. Deve ser incluído no arquivo de configuração. Para facilidade de uso, um alias é introduzido no código de configuração "vs". Natal de chaves в c["chaveFromDist"] são elementos fixos para interação com Construir Mestre. Para cada chave, o objeto correspondente é substituído como um valor.

Trabalhadores 5.2

c['workers'] = [worker.Worker("example-worker", "pass")]

Desta vez indicamos Construir Mestre-y lista de Trabalhador-s. Eu mesmo Trabalhador Nós criamos acima, indicando você-nome-do-trabalhador и senha. Agora eles precisam ser especificados trabalhador exemplo и passar .

5.3 mudança_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_da_mudança dicionário c temos acesso à lista onde queremos colocar um objeto que sonda o repositório com o código fonte do projeto. O exemplo usa um repositório Git que é pesquisado em determinados intervalos.

O primeiro argumento é o caminho para o seu repositório.

pasta de trabalho representa o caminho para a pasta onde ao lado Trabalhador-a em relação ao caminho /home/habr/worker/seuProjeto/build git armazenará a versão local do repositório.

ramo contém um branch específico no repositório que deve ser seguido.

pollInterval contém o número de segundos após os quais Construir Mestre pesquisará o repositório em busca de alterações.

Existem vários métodos para rastrear alterações no repositório de um projeto.

O método mais simples é Votação, o que implica que Construir Mestre pesquisa periodicamente o servidor com o repositório. Se commit refletiu as mudanças no repositório, então Construir Mestre criará um objeto interno com algum atraso Mudar e envie-o para o manipulador de eventos Scheduler, que lançará as etapas para construir e testar o projeto em Trabalhador-e. Dentre essas etapas serão indicadas atualizar repositório. Exatamente ligado TrabalhadorIsso criará uma cópia local do repositório. Os detalhes deste processo serão abordados abaixo nas próximas duas seções. (5.4 и 5.5).

Um método ainda mais elegante de rastrear alterações em um repositório é enviar mensagens diretamente do servidor que o hospeda para Construir Mestre- sobre a alteração dos códigos-fonte do projeto. Neste caso, assim que o desenvolvedor fizer commit, o servidor com o repositório do projeto enviará uma mensagem Construir Mestre- sim. E ele, por sua vez, irá interceptá-lo criando um objeto PBChangeSource. A seguir, este objeto será transferido para Scheduler, que ativa as etapas para construir o projeto e testá-lo. Uma parte importante deste método é trabalhar com gancho-scripts de servidor no repositório. No roteiro gancho-a, responsável por processar ações quando commit-e, você precisa chamar o utilitário enviar mudança e especifique o endereço de rede Construir Mestre-A. Você também precisa especificar a porta de rede que escutará PBChangeSource. PBChangeSource, aliás, faz parte Construir Mestre-A. Este método exigirá permissão admin-a no servidor onde o repositório do projeto está localizado. Primeiro você precisará fazer um backup do repositório.

5.4 agendadores


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 é um elemento que funciona como um gatilho que inicia toda a cadeia de montagem e testes do projeto.
Um exemplo de implementação de integração contínua usando BuildBot

Essas mudanças que foram registradas fonte_da_mudança, transformado no processo de trabalho BuildBotName-a para objetar Mudar e agora cada Sheduler com base neles, ele cria solicitações para iniciar o processo de construção do projeto. No entanto, também determina quando essas solicitações são transferidas para a fila. Um objeto Construtor armazena uma fila de solicitações e rastreia o estado da montagem atual em um separado Trabalhador-é. Construtor existe em Construir Mestre-e e assim por diante Trabalhador-e. Ele envia com Construir Mestre-a ligado Trabalhador-e já específico construir - uma série de etapas que devem ser seguidas.
Vemos que no exemplo atual tal programadores 2 peças são criadas. Além disso, cada um tem seu próprio tipo.

Agendador SingleBranch – uma das aulas mais concorridas da programação. Ele observa um ramo e é acionado por uma alteração registrada nele. Ao ver alterações, ele pode atrasar o envio da solicitação de construção (adiar pelo período especificado no parâmetro especial treeStableTimer) Em nome define o nome da programação que será exibida em BuildBotName-interface web. EM AlterarFiltro é definido um filtro, após passar quais alterações no ramal solicitam que o cronograma envie uma solicitação de construção. EM construtorNames nome é indicado construtor-a, que definiremos um pouco mais tarde. O nome em nosso caso será igual ao nome do projeto: seu projecto.

ForceScheduler uma coisa muito simples. Este tipo de agendamento é acionado por um clique do mouse BuildBotName-interface web. Os parâmetros têm a mesma essência que em Agendador SingleBranch.

PS nº 3. Talvez seja útil
Periódico é uma programação executada em uma determinada frequência com tempo fixo. A chamada é mais ou menos assim


from buildbot.plugins import schedulers
nightly = schedulers.Periodic(name="daily",
                              builderNames=["full-solaris"],
                              periodicBuildTimer=24*60*60)
c['schedulers'] = [nightly]                    

5.5 Construir Fábrica


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": "."}))

periódicoBuildTimer especifica o tempo desta periodicidade em segundos.

Construir fábrica cria um específico construir, qual então construtor envia para Trabalhador. Em Construir fábrica indica os passos a serem seguidos Trabalhador- sim. As etapas são adicionadas chamando o método adicionarEtapa

A primeira etapa adicionada neste exemplo é git limpo -d -f -f –xem seguida git check-out. Essas ações estão incluídas no parâmetro método, o que não é claramente declarado, mas implica um valor padrão recentes. Parâmetro modo='incremental' indica que os arquivos são do diretório onde o checar, embora ausentes do repositório, permanecem intocados.

A segunda etapa adicionada é chamar o script julgamento com parâmetro Olá do lado Trabalhador-a do diretório /home/habr/worker/seuProjeto/build com a variável de ambiente PATHONPATH=... Assim, você pode escrever seus próprios scripts e executá-los paralelamente Trabalhador-a cada passo util.ShellCommand. Esses scripts podem ser colocados diretamente no repositório. Então em checar-e eles vão cair /home/habr/worker/seuProjeto/build. No entanto, existem dois “mas”:

  1. Trabalhador deve ser criado com uma chave --umask para que não bloqueie os direitos de execução após checkout-a.
  2. em git push-e desses scripts você precisa especificar a propriedade executávelpara que mais tarde checar-e não perdeu o direito de executar o script Git.

5.6 construtores


c['builders'] = []
c['builders'].append(util.BuilderConfig(name="runtests",
                                        workernames=["example-worker"],
                                        factory=factory))

Sobre o que é Construtor foi dito aqui. Agora vou contar com mais detalhes sobre como criá-lo. BuilderConfig é um construtor construtor. Tais designers em c['construtores'] você pode especificar vários, pois esta é uma folha de objetos construtor tipo. Agora vamos reescrever o exemplo de BuildBotName, aproximando-o da nossa tarefa.


c['builders'] = []
c['builders'].append(util.BuilderConfig(name="yourProject",
                                            workernames=["yourWorkerName"],
                                            factory=factory))

Agora vou falar sobre os parâmetros BuilderConfig.

nome especifica o nome construtor-a. Aqui nós o nomeamos seu projecto... Isso significa que em Trabalhador- este mesmo caminho será criado /home/habr/worker/seuProjeto/build. Sheduler procurando por construtor apenas por este nome.

nomes de trabalhadores contém folha Trabalhador-s. Cada um dos quais deve ser adicionado a c['trabalhadores'].

fábrica - específico construir, ao qual está associado construtor. Ele enviará o objeto construir em Trabalhador para concluir todas as etapas incluídas neste construir-a.

6. Exemplo de sua própria configuração

Aqui está o exemplo de arquitetura de projeto que proponho implementar via BuildBotName
.

Usaremos como sistema de controle de versão svn. O repositório em si estará localizado em algum tipo de nuvem. Aqui está o endereço desta nuvem svn.host/svn/seuProjeto/trunk. Na nuvem abaixo svn existe um nome de usuário da conta: usuário, senha: senha. Scripts que representam etapas construir-a também estará no branch svn, em uma pasta separada buildbot/worker_linux. Esses scripts estão localizados no repositório com a propriedade salva executável.

Construir Mestre и Trabalhador executado no mesmo host projeto.host .Construir Mestre armazena seus arquivos em uma pasta /home/habr/master. Trabalhador ele é armazenado no seguinte caminho /home/habr/trabalhador. Comunicação de processo Construir Mestre-a eu Trabalhador-a é realizado através da porta 4000 de acordo com o protocolo BuildBotName-a, isso é 'pb' protocolo.

O projeto alvo é escrito inteiramente em Python. A tarefa é rastrear suas alterações, criar um arquivo executável, gerar documentação e realizar testes. Em caso de falha, todos os desenvolvedores precisam enviar uma mensagem por e-mail informando que há uma ação malsucedida.

Exibição na web BuildBotName vamos nos conectar à porta 80 para projeto.host. Não é necessário instalar o Apatch. Como parte da biblioteca retorcido já existe um servidor web, BuildBotName usa.

Para armazenar informações internas para BuildBotName nós vamos usar sqlite.

É necessário um host para enviar correspondência smtp.seu.domínio - permite enviar cartas do correio [email protegido] sem autenticação. Também no host 'smtp ' A ata está sendo ouvida no posto 1025.

Existem duas pessoas envolvidas no processo: admin и usuário. administrador administra BuildBotName. usuário é a pessoa que comete commit-s.

O arquivo executável é gerado via pyinstaller. A documentação é gerada via doxigênio.

Para esta arquitetura eu escrevi 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 você precisa criar Construir Mestre-a eu Trabalhador-a. Então cole este arquivo mestre.cfg в /home/habr/master.

O próximo passo é iniciar o serviço Construir Mestreaa


sudo buildbot start /home/habr/master

Então inicie o serviço Trabalhador-a


buildbot-worker start /home/habr/worker

Preparar! Agora Construir bot rastreará as alterações e acionará commit-você entra svn, executando as etapas de construção e teste de um projeto com a arquitetura acima.

Abaixo descreverei alguns recursos do acima mestre.cfg.

6.1 A caminho do seu master.cfg


Enquanto escrevo meu mestre.cfg Muitos erros serão cometidos, portanto será necessária a leitura do arquivo de log. Ele é armazenado como Construir Mestre-ec caminho absoluto /home/habr/master/twistd.log, e ao lado Trabalhador-a com caminho absoluto /home/habr/worker/twistd.log. Ao ler o erro e corrigi-lo, você precisará reiniciar o serviço Construir Mestre-a. Veja como isso é feito:


sudo buildbot stop /home/habr/master
sudo buildbot upgrade-master /home/habr/master
sudo buildbot start /home/habr/master

6.2 Trabalhando com 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)

Primeiro, vamos dar uma olhada svn_poller. Esta ainda é a mesma interface, pesquisando regularmente o repositório uma vez por minuto. Nesse caso svn_poller só acessa a filial tronco. Parâmetro misterioso split_file=util.svn.split_file_alwaystrunk define as regras: como quebrar a estrutura de pastas svn nos galhos. Ele também lhes oferece caminhos relativos. Por sua vez split_file_alwaystrunk simplifica o processo dizendo que o repositório contém apenas tronco.

В Agendadores é indicado AlterarFiltroquem vê nenhum e associa uma filial a ela tronco de acordo com uma determinada associação através split_file_alwaystrunk. Respondendo às mudanças tronco, Lançamentos construtor com nome seu projecto.

Propriedades aqui é necessário para que o administrador receba listas de discussão de resultados de construção e teste como proprietário do processo.

Passo construir-a checkout capaz de excluir completamente quaisquer arquivos localizados na versão local do repositório Trabalhador-A. E então faça o completo atualização svn. O modo é configurado através do parâmetro modo = completo, método=fresco. Parâmetro haltOnTailure diz que se atualização svn será executado com erro, então todo o processo de construção e teste deverá ser suspenso, pois ações posteriores não fazem sentido.

6.3 Carta para você: os repórteres estão autorizados a declarar


jornalistas é um serviço de envio de notificações por email.


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]

Ele pode enviar mensagens jeitos diferentes.

MailNotificador usa e-mail para enviar notificações.

modelo_html define o modelo de texto para o boletim informativo. HTML é usado para criar marcação. É modificado pelo motor Jinja2 (pode ser comparado com django). BuildBotName possui um conjunto de variáveis ​​cujos valores são substituídos no template durante o processo de geração do texto da mensagem. Essas variáveis ​​​​são colocadas entre {{ chaves duplas }}. Por exemplo, resumo exibe o status das operações concluídas, ou seja, sucesso ou falha. A projetos produzirá seu projecto. Então, usando comandos de controle em Jinja2, variáveis BuildBotName-a e ferramentas de formatação de string python, você pode criar uma mensagem bastante informativa.

MailNotificador contém os seguintes argumentos.

fromaddr – o endereço de onde todos receberão a newsletter.

enviarToInterestedUsers=True envia uma mensagem para o proprietário e usuário que fez commit.

pesquisa — um sufixo que deve ser adicionado aos nomes dos usuários que recebem a newsletter. Então admin como o usuário receberá a newsletter no endereço [email protegido].

host de retransmissão especifica o nome do host no qual o servidor está aberto smtp, um smptPort especifica o número da porta que escuta smtp servidor.

modo = "aviso" diz que o mailing só deve ser feito se houver pelo menos uma etapa construir-a, que terminou com falha ou aviso de status. Em caso de sucesso, não há necessidade de envio de newsletter.

extraRecipients contém uma lista de pessoas para quem a correspondência deve ser enviada, além do proprietário e da pessoa que realizou a correspondência commit.

mensagemFormatter é um objeto que especifica o formato da mensagem, seu modelo e um conjunto de variáveis ​​disponíveis em Jinja2. Opções como quererPropriedades = Verdadeiro и querPassos = Verdadeiro defina este conjunto de variáveis ​​disponíveis.

com['serviços']=[sendMessageToAll] fornece uma lista de serviços, entre os quais o nosso será repórter.

Conseguimos! Parabéns

Criamos nossa própria configuração e vimos a funcionalidade que ela é capaz. BuildBotName. Acho que isso é suficiente para entender se essa ferramenta é necessária para criar seu projeto. Você está interessado nele? Será útil para você? Ele se sente confortável para trabalhar? Então não estou escrevendo este artigo em vão.

E mais longe. Eu gostaria que a comunidade profissional usasse BuildBotName, tornou-se mais amplo, manuais foram traduzidos e houve ainda mais exemplos.

Obrigado a todos pela atenção. Boa sorte.

Fonte: habr.com

Adicionar um comentário