Integración continua "Pretty" para Python

No sé si sería : Mordido es 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 utilizando nose como nuestro corredor de pruebas. Teamcity plugin for nosetests le da cuenta de pasar/fallar, pantalla legible para la prueba fallida( que puede ser enviado por correo electrónico). Incluso puede ver detalles de los errores de prueba mientras se ejecuta la pila.

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

La página de cascada de Buildbot puede ser considerablemente embellecida. He aquí un buen ejemplo http://build.chromium.org/buildbot/waterfall/waterfall

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

Supongo que este hilo es bastante viejo, pero aquí está mi opinión sobre él con Hudson:

Decidí ir con pip y configurar un repo (el doloroso para conseguir trabajo, pero bonito aspecto eggbasket), que hudson auto carga con una prueba exitosa. Aquí está mi script en bruto 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 WORKSPACE-p my.package-v BUIL BUILD_NUMBER, solo tienes que poner * * / coverage.xml, pylint.txt y nosetests.xml en la configuración bits:

#!/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 entonces la gente puede desarrollar cosas usando:

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

Esto supone que tienes una estructura de repo por paquete con un setup.py y todas las dependencias configuradas, entonces puedes simplemente echar un vistazo al tronco y ejecutar estas cosas 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 config con la carpeta html

Tenga en cuenta que pip no admite la bandera-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ás considerando una solución de CI alojada, y haciendo código abierto, deberías mirar Travis CI también - tiene una integración muy agradable con GitHub. Si bien comenzó como una herramienta Ruby, ha agregado soporte para Python hace un tiempo.

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

Consideraría CircleCI - tiene un gran soporte de Python, y una salida muy bonita.

Continuum binstar ahora es capaz de activar compilaciones desde github y puede compilar para linux, osx y windows ( 32 / 64 ). lo bueno es que realmente le permite acoplar de cerca la distribución y la integración continua. Eso es cruzar las t y salpicar las I de 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 pitónica de distribuir módulos python complejos, donde necesita envolver y distribuir Bibliotecas C/C++ / Futran.

Hemos usado bitten bastante. Es bonito y se integra bien con Trac, pero es un dolor en el trasero para personalizar si tiene cualquier flujo de trabajo no estándar. También simplemente no hay tantos plugins como los hay para las herramientas más populares. Actualmente estamos evaluando a Hudson como reemplazo.

Compruebe 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, incluyendo Python.

Pequeño descargo de responsabilidad, en realidad he tenido que construir una solución como esta para un cliente que quería una forma de probar e implementar automáticamente cualquier código en un git push además de administrar los tickets de emisión a través de git notes. Esto también llevó a mi trabajo en el proyecto AIMS.

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

Aunque, no esperaría que nadie más que un tipo de UNIX Graybeard o un ingeniero/arquitecto a nivel de Principio llegara realmente tan lejos. Solo es una buena idea y una experiencia de aprendizaje potencial, ya que un servidor de compilación no es más que una forma de ejecutar arbitrariamente tareas con scripts de manera automatizada.