& # 8220; Bonito & # 8221; Integración continua para Python

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

Pregunta

Esta es una pregunta un poco vana, pero la salida de BuildBot no es particularmente agradable de ver ...

Por ejemplo, comparado con ...

... y otros, BuildBot parece más bien ... arcaico

Actualmente estoy jugando con Hudson, pero está muy centrado en Java (aunque con esta guía , me pareció más fácil de configurar que BuildBot y generé más información)

Básicamente: ¿hay algún sistema de integración continua dirigido a python que produzca muchos gráficos brillantes y similares?

Actualización: Desde este momento, el proyecto Jenkins ha reemplazado a Hudson como la versión comunitaria del paquete. Los autores originales también se han trasladado a este proyecto. Jenkins ahora es un paquete estándar en Ubuntu / Debian, RedHat / Fedora / CentOS, y otros. La siguiente actualización sigue siendo esencialmente correcta. El punto de partida para hacer esto con Jenkins es diferente.

Update: Después de probar algunas alternativas, creo que me quedaré con Hudson. Integrity fue agradable y simple, pero bastante limitado. Creo que Buildbot es más adecuado para tener numerosos esclavos de compilación, en lugar de que todo funcione en una sola máquina como la que estaba usando it.

Configurar Hudson para un proyecto en Python fue bastante simple:

  • Descargue Hudson desde http://hudson-ci.org/
  • Ejecutarlo con java -jar hudson.war
  • Abra la interfaz web en la dirección predeterminada de http://localhost:8080
  • Vaya a Administrar Hudson, Complementos, haga clic en " Actualizar " o similar
  • Instalar el complemento Git (tuve que configurar la ruta git en las preferencias globales de Hudson)
  • Cree un nuevo proyecto, ingrese el repositorio, los intervalos de sondeo de SCM, etc.
  • Instale nosetests a través de easy_install si aún no lo ha hecho
  • En el paso de compilación, agregue nosetests --with-xunit --verbose
  • Verificar " Publicar informe de resultados de prueba de JUnit " y establecer " Test XMLs de informe " a **/nosetests.xml

Eso es todo lo que se requiere. Puede configurar las notificaciones por correo electrónico y los complementos merecen una mirada. Algunos de los que estoy usando actualmente para proyectos de Python:

  • complemento de SLOCCount para contar líneas de código (¡y graficarlo! ): debe instalar sloccount por separado
  • Violaciones para analizar la salida de PyLint (puede configurar umbrales de advertencia, gráfico el número de violaciones en cada compilación)
  • Cobertura puede analizar la salida deverage.py. Nosetest puede recopilar cobertura mientras ejecuta sus pruebas, utilizando nosetests --with-cover (esto escribe el resultado en ** / coverage.xml )
¿Fue útil?

Solución

Es posible que desee consultar Nose y el complemento de salida de Xunit . Puede hacer que ejecute sus pruebas unitarias y verificaciones de cobertura con este comando: 

nosetests --with-xunit --enable-cover

Eso será útil si desea ir a la ruta de Jenkins o si desea usar otro servidor de CI que sea compatible con los informes de prueba de JUnit.

De forma similar, puede capturar la salida de pylint utilizando el complemento de violaciones para Jenkins

Otros consejos

No sé si lo haría: Bitten está hecho por los chicos que escriben Trac y está integrado con Trac. Apache Gump es la herramienta de CI utilizada por Apache. Está escrito en Python.

Hemos tenido un gran éxito con TeamCity como nuestro servidor de CI y usamos nose como nuestro corredor de pruebas . El complemento de Teamcity para las pruebas más novedosas le da un recuento pasable / fallido, legible para la prueba fallida (que puede ser enviado por correo electrónico). Incluso puede ver detalles de las fallas de prueba mientras se está ejecutando la pila.

Si, por supuesto, admite cosas como ejecutarse en múltiples máquinas, y es mucho más sencillo de configurar y mantener que buildbot.

La página de la cascada de Buildbot puede ser bastante hermosa. Aquí hay un buen ejemplo http://build.chromium.org/buildbot/waterfall/waterfall

Bamboo de Atlassian también merece la pena echarle un vistazo. Toda la suite de Atlassian (JIRA, Confluence, FishEye, etc.) es bastante dulce.

Supongo que este hilo es bastante antiguo, pero aquí está mi opinión sobre hudson:

Decidí ir con pip y configurar un repositorio (el doloroso para empezar a trabajar, pero el buen aspecto de la canasta de huevos), que hudson carga automáticamente con pruebas exitosas. Aquí está mi script básico y listo para usar con un script de ejecución de configuración de hudson como: /var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER, solo coloque ** / cover.xml, pylint.txt y nosetests.xml en los bits de configuración: 

#!/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()

Cuando se trata de implementar cosas, puedes hacer algo como: 

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

Y luego la gente puede desarrollar cosas usando: 

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

Este material asume que tienes una estructura de recompra por paquete con un setup.py y todas las dependencias están configuradas, entonces puedes revisar el tronco y ejecutar este material en él.

Espero que esto ayude a alguien.

------ actualización ---------

He añadido epydoc que encaja muy bien con hudson. Simplemente agregue javadoc a su configuración con la carpeta html

Tenga en cuenta que pip no admite la marca -E correctamente en estos días, por lo que debe crear su venv por separado

otro: Shining Panda es una herramienta alojada para python

Si está considerando una solución de CI alojada, y está haciendo una fuente abierta, debería considerar Travis CI como Bueno, tiene muy buena integración con GitHub. Aunque comenzó como una herramienta de Ruby, tienen servicio de soporte añadido de Python hace un tiempo.

La señal es otra opción. Puede saber más sobre esto y ver un video también aquí .

Consideraría CircleCi - tiene un excelente soporte de Python y un resultado muy bonito.

Continum binstar ahora es capaz de activar compilaciones desde github y puede compilar para Linux, osx y windows (32/64). Lo bueno es que realmente te permite unir la distribución y la integración continua. Eso es cruzar las t's y salpicar las I's de la integración. El sitio, el flujo de trabajo y las herramientas están realmente pulidos y AFAIK conda es la forma más robusta y pirónica de distribuir módulos complejos de Python, donde necesita envolver y distribuir bibliotecas C / C ++ / Fotran.

Hemos utilizado un poco mordido. Es bonito y se integra bien con Trac, pero es una molestia personalizarlo si tiene un flujo de trabajo no estándar. Además, simplemente no hay tantos complementos como los que hay para las herramientas más populares. Actualmente estamos evaluando a Hudson como un reemplazo.

Marque rultor.com . Como este artículo explica, utiliza Docker para cada compilación . Gracias a eso, puedes configurar lo que quieras dentro de tu imagen de Docker, incluido Python.

Poco descargo de responsabilidad, en realidad tuve que crear una solución como esta para un cliente que quería una forma de probar y desplegar automáticamente el código cualquiera en un git push, además de gestionar los tickets de problemas a través de las notas de git . Esto también condujo a mi trabajo en el proyecto AIMS .

Uno podría fácilmente configurar un sistema de nodo simple que tenga un usuario de compilación y administrar su compilación a través de make (1) , expect (1) , crontab (1) / systemd.unit (5) , y incrontab (1) . Incluso se podría ir un paso más allá y usar ansible y apio para compilaciones distribuidas con un almacén de archivos gridfs / nfs.

Sin embargo, no esperaría que nadie más que un técnico de Graybeard UNIX o un ingeniero / arquitecto de nivel de Principios realmente llegue tan lejos. Simplemente es una buena idea y una posible experiencia de aprendizaje, ya que un servidor de compilación no es más que una forma de ejecutar tareas de script de manera automática y arbitraria.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top