“Pretty” Integração Contínua para Python

StackOverflow https://stackoverflow.com/questions/225598

Pergunta

Este é um pouco .. questão vão, mas a saída de buildbot não é particularmente agradável ao olhar ..

Por exemplo, em comparação com ..

.. e outros, buildbot parece bastante .. arcaica

Atualmente estou jogando com Hudson, mas é muito Java-centric (embora com este guia , eu achei mais fácil de configurar do que buildbot, e produziu mais info)

Basicamente:? Há quaisquer sistemas de integração contínua destinadas a python, que os lotes do produto de gráficos brilhantes e os gostos

Update: Desde essa altura o projeto Jenkins substituiu Hudson como a versão da comunidade do pacote. Os autores originais mudaram-se para este projecto também. Jenkins é agora um pacote padrão no Ubuntu / Debian, RedHat / Fedora / CentOS, e outros. A atualização seguinte ainda é essencialmente correta. O ponto de partida para fazer isso com Jenkins é diferente.

Atualização: Depois de tentar algumas alternativas, eu acho que vou ficar com Hudson. Integridade era agradável e simples, mas bastante limitado. Acho Buildbot é mais adequado para ter inúmeros build-escravos, em vez de tudo funcionando em uma única máquina como eu estava usando -lo.

Configuração Hudson-se de um projeto Python era muito simples:

  • Baixar Hudson de http://hudson-ci.org/
  • Executar com java -jar hudson.war
  • Abra a interface web no endereço padrão de http://localhost:8080
  • Vá para Gerenciar Hudson, Plugins, clique em "Update" ou similar
  • Instale o plug-in Git (eu tinha que definir o caminho git nas preferências globais Hudson)
  • Crie um novo projeto, digite o repositório, intervalos de SCM de votação e assim por diante
  • Instale nosetests via easy_install se não é já
  • Na etapa de uma compilação, adicione nosetests --with-xunit --verbose
  • Marque a opção "Publicar JUnit relatório de resultado de teste" e set "Teste XMLs relatório" para **/nosetests.xml

Isso é tudo que é necessário. Você pode notificações de configuração de e-mail, e os plugins são olhar uma pena. Alguns Eu estou usando atualmente para projetos Python:

  • SLOCCount plug-in para contagem de linhas de código (e gráfico-lo! ) - você precisa instalar sloccount separadamente
  • Violações para analisar a saída pylint (você pode limiares de alerta de configuração, gráfico o número de violações sobre cada compilação)
  • Cobertura pode analisar a saída coverage.py. Nosetest pode reunir cobertura durante a execução de seus testes, usando nosetests --with-coverage (isso escreve a saída para **/coverage.xml)
Foi útil?

Solução

Você pode querer verificar para fora Nariz e a saída xUnit plug-in . Você pode tê-lo executar os testes de unidade e verificações de cobertura com este comando: 

nosetests --with-xunit --enable-cover

Isso vai ser útil se você quiser ir a rota Jenkins, ou se você quiser usar outro servidor CI que tenha suporte para relatórios de teste JUnit.

Da mesma forma, você pode capturar a saída de pylint usando os violações plugin para Jenkins

Outras dicas

Não sei se ele faria: Bitten é feita pelos caras que escrevem Trac e está integrado com Trac. Apache Gump é a ferramenta CI usado pelo Apache. Ele é escrito em Python.

Temos tido grande sucesso com TeamCity como o nosso servidor de CI e usando nariz como o nosso corredor de teste . TeamCity plugin para nosetests dá-lhe contar aprovação / reprovação, display legível para o teste falhou (que pode ser enviada por correio electrónico). Você pode até ver detalhes das falhas do teste, enquanto você pilha está em execução.

Se de suportes curso coisas como correr em várias máquinas, e é muito mais simples de configurar e manter do que buildbot.

página cachoeira do Buildbot pode ser consideravelmente enfeitada. Aqui está um exemplo agradável http://build.chromium.org/buildbot/waterfall/waterfall

Atlassian do Bamboo também é definitivamente vale a pena conferir. Todo o conjunto Atlassian (JIRA, Confluence, Olho de peixe, etc) é muito doce.

Eu acho que esta discussão é antiga, mas aqui é minha opinião sobre ele com hudson:

Eu decidi ir com pip e criar um repo (o doloroso para começar a trabalhar, mas olhando agradável eggbasket), que hudson auto uploads para com testes bem sucedidos. Aqui está o meu áspero e roteiro pronto para uso com um hudson configuração executar o script como: /var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER, basta colocar em ** / coverage.xml, pylint.txt e nosetests.xml nos bits de configuração: 

#!/var/lib/hudson/venv/main/bin/python
import os
import re
import subprocess
import logging
import optparse

logging.basicConfig(level=logging.INFO,
                    format='%(asctime)s %(levelname)s %(message)s')

#venvDir = "/var/lib/hudson/venv/main/bin/"

UPLOAD_REPO = "http://ldndev01:3442"

def call_command(command, cwd, ignore_error_code=False):
    try:
        logging.info("Running: %s" % command)
        status = subprocess.call(command, cwd=cwd, shell=True)
        if not ignore_error_code and status != 0:
            raise Exception("Last command failed")

        return status

    except:
        logging.exception("Could not run command %s" % command)
        raise

def main():
    usage = "usage: %prog [options]"
    parser = optparse.OptionParser(usage)
    parser.add_option("-w", "--workspace", dest="workspace",
                      help="workspace folder for the job")
    parser.add_option("-p", "--package", dest="package",
                      help="the package name i.e., back_office.reconciler")
    parser.add_option("-v", "--build_number", dest="build_number",
                      help="the build number, which will get put at the end of the package version")
    options, args = parser.parse_args()

    if not options.workspace or not options.package:
        raise Exception("Need both args, do --help for info")

    venvDir = options.package + "_venv/"

    #find out if venv is there
    if not os.path.exists(venvDir):
        #make it
        call_command("virtualenv %s --no-site-packages" % venvDir,
                     options.workspace)

    #install the venv/make sure its there plus install the local package
    call_command("%sbin/pip install -e ./ --extra-index %s" % (venvDir, UPLOAD_REPO),
                 options.workspace)

    #make sure pylint, nose and coverage are installed
    call_command("%sbin/pip install nose pylint coverage epydoc" % venvDir,
                 options.workspace)

    #make sure we have an __init__.py
    #this shouldn't be needed if the packages are set up correctly
    #modules = options.package.split(".")
    #if len(modules) > 1: 
    #    call_command("touch '%s/__init__.py'" % modules[0], 
    #                 options.workspace)
    #do the nosetests
    test_status = call_command("%sbin/nosetests %s --with-xunit --with-coverage --cover-package %s --cover-erase" % (venvDir,
                                                                                     options.package.replace(".", "/"),
                                                                                     options.package),
                 options.workspace, True)
    #produce coverage report -i for ignore weird missing file errors
    call_command("%sbin/coverage xml -i" % venvDir,
                 options.workspace)
    #move it so that the code coverage plugin can find it
    call_command("mv coverage.xml %s" % (options.package.replace(".", "/")),
                 options.workspace)
    #run pylint
    call_command("%sbin/pylint --rcfile ~/pylint.rc -f parseable %s > pylint.txt" % (venvDir, 
                                                                                     options.package),
                 options.workspace, True)

    #remove old dists so we only have the newest at the end
    call_command("rm -rfv %s" % (options.workspace + "/dist"),
                 options.workspace)

    #if the build passes upload the result to the egg_basket
    if test_status == 0:
        logging.info("Success - uploading egg")
        upload_bit = "upload -r %s/upload" % UPLOAD_REPO
    else:
        logging.info("Failure - not uploading egg")
        upload_bit = ""

    #create egg
    call_command("%sbin/python setup.py egg_info --tag-build=.0.%s --tag-svn-revision --tag-date sdist %s" % (venvDir,
                                                                                                              options.build_number,
                                                                                                              upload_bit),
                 options.workspace)

    call_command("%sbin/epydoc --html --graph all %s" % (venvDir, options.package),
                 options.workspace)

    logging.info("Complete")

if __name__ == "__main__":
    main()

Quando se trata de implantação de coisas que você pode fazer algo como: 

pip -E /location/of/my/venv/ install my_package==X.Y.Z --extra-index http://my_repo

E, em seguida, as pessoas podem desenvolver o material usando: 

pip -E /location/of/my/venv/ install -e ./ --extra-index http://my_repo

Este material assume que você tem uma estrutura de repo por pacote com um setup.py e dependências tudo configurado, então você pode apenas verificar o tronco e executar este coisas sobre ele.

Espero que isso ajude alguém.

------ --------- atualização

Eu adicionei epydoc que se encaixa muito bem com Hudson. Basta adicionar javadoc para sua configuração com o html pasta

Note que pip não suporta a bandeira -E adequadamente estes dias, então você tem que criar o seu venv separadamente

outra: Brilhante Panda é uma ferramenta hospedada para python

Se você está considerando uma solução CI hospedado, e fazendo open source, você deve olhar para Travis CI como bem - ele tem muito agradável integração com GitHub. Embora começou como uma ferramenta Ruby, eles têm adicionou suporte Python href="http://about.travis-ci.org/blog/announcing_python_and_perl_support_on_travis_ci/" um tempo atrás.

Signal é outra opção. Você pode saber mais sobre ele e assistir a um vídeo também aqui .

Eu consideraria CircleCi -. Ele tem grande apoio Python, e saída muito bonita

binstar agora é capaz de gatilho constrói a partir github e pode compilar para Linux, OSX e janelas (32/64). A coisa pura é que ele realmente permite a distribuição de perto casal e integração contínua. Que está atravessando o t da e que pontilham a I é de Integração. O site, fluxo de trabalho e ferramentas são realmente polido e AFAIK Conda é a forma mais robusta e pythônico para distribuir módulos python complexos, em que você precisa para embrulhar e distribuir bibliotecas C / C ++ / Fotran.

Temos usado mordido um pouco. É bonita e integra bem com Trac, mas é uma dor na bunda para personalizar se você tem qualquer fluxo de trabalho fora do padrão. Também há apenas não são tão muitos plugins como existem para as ferramentas mais populares. Atualmente estamos avaliando Hudson como uma substituição.

Verifique rultor.com . Como este artigo explica, ele usa Docker para cada compilação . Graças a isso, você pode configurar o que quiser dentro de sua imagem Docker, incluindo Python.

Little aviso legal, eu realmente tive que construir uma solução como esta para um cliente que queria uma maneira de automaticamente testar e implantar qualquer código em um git push além de gerir os emitir bilhetes via notas git . Isso também levar a minha obra sobre os AIMS projetar .

Pode-se facilmente apenas configurar um sistema de nó nu que tem um usuário construir e gerenciar sua construção através make(1), expect(1), crontab(1) / systemd.unit(5) e incrontab(1). Pode-se até dar um passo adiante e usar ansible e aipo para distribuídos constrói com um armazenamento de arquivos GridFS / NFS.

Embora, eu não esperaria que alguém que não seja um cara Ancião UNIX ou Princípio engenheiro de nível / arquiteto para realmente ir tão longe. Apenas faz para uma ideia agradável e experiência de aprendizagem potencial desde um servidor de compilação é nada mais do que uma maneira de tarefas arbitrariamente executar scripts de forma automatizada.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top