& # 8220; Jolie & # 8221; Intégration continue pour Python

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

Question

C’est une question un peu .. vaine, mais la sortie de BuildBot n’est pas particulièrement agréable à regarder ..

Par exemple, comparé à ..

.. et autres, BuildBot ont plutôt l'air .. archaïque

Je joue actuellement avec Hudson, mais il est très centré sur Java (bien qu'avec ce guide , je l'ai trouvé plus facile à configurer que BuildBot et j'ai généré plus d'informations)

En gros: existe-t-il des systèmes d’intégration continue destinés à Python, qui produisent beaucoup de graphes brillants et similaires?

Mise à jour: Depuis lors, le projet Jenkins a remplacé Hudson en tant que version communautaire du package. Les auteurs originaux ont également migré vers ce projet. Jenkins est maintenant un paquet standard sur Ubuntu / Debian, RedHat / Fedora / CentOS, etc. La mise à jour suivante est toujours essentiellement correcte. Le point de départ pour ce faire avec Jenkins est différent.

Mise à jour: Après avoir essayé quelques alternatives, je pense que je vais rester avec Hudson. L'intégrité était simple et agréable, mais assez limité. Je pense que Buildbot est plus approprié pour avoir de nombreux esclaves de construction, plutôt que de tout exécuter sur une seule machine comme celle que j'utilisais il.

Configurer Hudson pour un projet Python était assez simple:

  • Téléchargez Hudson depuis http://hudson-ci.org/
  • Exécutez-le avec java -jar hudson.war
  • Ouvrez l'interface Web sur l'adresse par défaut http: // localhost: 8080
    • .
  • Accédez à Gérer Hudson, Modules externes, cliquez sur "Mettre à jour". ou similaire
  • Installez le plugin Git (je devais définir le chemin git dans les préférences globales de Hudson)
  • Créez un nouveau projet, entrez le référentiel, les intervalles d'interrogation SCM, etc.
  • Installez nosetests via easy_install si ce n'est déjà fait
  • Dans l'étape de construction, ajoutez nosetests --with-xunit --verbose
  • Cochez la case "Publier le résultat du test JUnit". et définissez " XML de rapport de test " vers ** / nosetests.xml

C'est tout ce qui est nécessaire. Vous pouvez configurer les notifications par courrier électronique. Les plugins valent le détour. Quelques-uns que j'utilise actuellement pour les projets Python:

  • plug-in SLOCCount pour compter les lignes de code (et les représenter graphiquement!). ) - vous devez installer sloccount séparément
  • Violations pour analyser la sortie PyLint (vous pouvez configurer des seuils d'avertissement, un graphique le nombre de violations sur chaque build)
  • Cobertura peut analyser le résultat de couverture.py. Nosetest peut obtenir une couverture lors de l'exécution de vos tests, en utilisant nosetests --with-couverture (ceci écrit le résultat dans ** / coverage.xml )
Était-ce utile?

La solution

Vous pouvez consulter Nez et le plug-in de sortie Xunit . Vous pouvez le faire exécuter vos tests unitaires et vos vérifications de couverture avec cette commande: 

nosetests --with-xunit --enable-cover

Cela vous sera utile si vous souhaitez suivre la route Jenkins ou si vous souhaitez utiliser un autre serveur de CI qui prend en charge les rapports de test JUnit.

De même, vous pouvez capturer la sortie de pylint à l'aide du plug-in de violation pour Jenkins .

Autres conseils

Je ne sais pas si cela suffirait: Bitten est créé par les auteurs de Trac et est intégré. avec Trac. Apache Gump est l'outil de CI utilisé par Apache. Il est écrit en Python.

Nous avons eu beaucoup de succès avec TeamCity en tant que serveur CI et en utilisant nez comme testeur. . Le plug-in Teamcity pour nosetests vous donne le nombre de succès / échecs, un affichage lisible pour les tests ayant échoué (qui être envoyé par courrier électronique). Vous pouvez même voir les détails des échecs de test pendant que votre pile est en cours d'exécution.

Si, bien sûr, vous pouvez exécuter des tâches telles que l'exécution sur plusieurs ordinateurs, et qu'il est beaucoup plus simple à installer et à gérer que buildbot.

La page cascade de Buildbot peut être considérablement améliorée. Voici un bel exemple http://build.chromium.org/buildbot/waterfall/waterfall

Le Bamboo d'Atlassian mérite également une visite. L'ensemble de la suite Atlassian (JIRA, Confluence, FishEye, etc.) est plutôt sympathique.

Je suppose que ce fil est assez ancien, mais voici ce que je pense avec hudson:

J’ai décidé d’y aller avec pip et de mettre en place un repo (le support douloureux pour aller travailler mais un joli panier d’oeufs), que hudson a chargé automatiquement avec des tests réussis. Voici mon script approximatif à utiliser avec un script hudson config execute, tel que: /var/lib/hudson/venv/main/bin/hudson_script.py -w $ WORKSPACE -p my.package -v $ BUILD_NUMBER, venez de mettre ** / coverage.xml, pylint.txt et nosetests.xml dans les bits de configuration: 

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

En ce qui concerne le déploiement d'éléments, vous pouvez faire quelque chose comme: 

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

Et ensuite, les gens peuvent développer des choses en utilisant: 

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

Ce genre de choses suppose que vous avez une structure de référentiel par paquet avec un fichier setup.py et que toutes les dépendances sont configurées, vous pouvez simplement vérifier le tronc et y exécuter ce genre de choses.

J'espère que cela aidera quelqu'un.

------ mettre à jour ---------

J'ai ajouté epydoc qui convient parfaitement à hudson. Ajoutez simplement javadoc à votre configuration avec le dossier html

Notez que pip ne supporte pas correctement l'indicateur -E, vous devez donc créer votre venv séparément

un autre: Shining Panda est un outil hébergé pour python

Si vous envisagez une solution CI hébergée et optez pour une source ouverte, vous devez vous reporter à CI Travis en tant que bien - il a une très belle intégration avec GitHub. Bien qu’il s’agisse au départ d’un outil Ruby, il a ajouté le support Python . / p>

Le signal est une autre option. Vous pouvez en savoir plus et regarder une vidéo aussi ici .

Je considérerais CircleCi : il offre un excellent support Python et une très belle sortie.

binstar du processus continuum est maintenant en mesure de déclencher la construction à partir de github et de compiler pour linux, osx et windows (32/64). Ce qui est bien, c’est que cela vous permet vraiment de coupler étroitement la distribution et l’intégration continue. C'est traverser le t et le I de l'intégration. Le site, le flux de travail et les outils sont vraiment raffinés et AFAIK conda est le moyen le plus robuste et pythonique de distribuer des modules python complexes, où vous devez encapsuler et distribuer des bibliothèques C / C ++ / Fotran.

Nous avons utilisé pas mal de choses. Il est joli et s’intègre bien avec Trac, mais il est difficile de le personnaliser si vous avez un flux de travail non standard. De plus, il n'y a tout simplement pas autant de plugins que pour les outils les plus populaires. Nous évaluons actuellement Hudson en tant que remplaçant.

Vérifiez rultor.com . Comme cet article , il utilise Docker pour chaque version . Grâce à cela, vous pouvez configurer ce que vous voulez dans votre image Docker, y compris Python.

Petit avertissement, j'ai en fait dû créer une solution comme celle-ci pour un client qui souhaitait un moyen de tester et de déployer automatiquement tout code sur un git push et de gérer les tickets d'émission via des notes git. . Cela a également conduit à mon travail sur le projet AIMS .

On pourrait facilement configurer un système à nœud nu avec un utilisateur de build et gérer sa construction via make (1) , expect (1) , crontab (1) / systemd.unit (5) et incrontab (1) . On pourrait même aller plus loin et utiliser ansible et céleri pour les versions distribuées avec un magasin de fichiers gridfs / nfs.

Bien que, je ne m'attende pas à ce que quelqu'un d'autre qu'un Graybeard UNIX ou un ingénieur / architecte de niveau principal aille aussi loin. Une bonne idée et une expérience d’apprentissage potentielle, puisqu’un serveur de build n’est rien de plus qu’un moyen d’exécuter de manière arbitraire des tâches scriptées de manière automatisée.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top