Jobs pipeline¶

Deux jobs jenkins par projet : un job projectname et un job projectname-wip.
Les deux jobs utilisent le même Jenkinsfile, placé à la racine du dépôt git du projet projectname.

• utilise tox pour exécuter les tests (qui lui même utilise pytest et pylint)
• build les paquets debian (si il est appelé par le job projectname)
• publie les rapports de tests, coverage, pylint
• notifie les résultats de build par mail (par https://wiki.jenkins.io/display/JENKINS/Mailer)

Une libraire est utilisé pour éviter la redondance entre les Jenkinsfile des différents projets (http://git.entrouvert.org/jenkins-lib.git/).

Documentation jenkins pipeline : https://jenkins.io/doc/book/pipeline/
Documentation jenkins shared library : https://jenkins.io/doc/book/pipeline/shared-libraries/

Job projectname¶

• job de type pipeline
• ne s'exécute que sur la branche master (déclenchement automatique par scrutation de changements sur le dépôt git toutes les 5 minutes, et à défaut de changements une fois par jour)
• exécute les tests, ne build pas les paquets debian
• notifie les résultats de build par mail à une liste de diffusion : admin+jenkins-projectname@entrouvert.com

Job projectname-wip¶

• job de type pipeline multibranch
• s'exécute que sur les branches wip/* (déclenchement automatique par scrutation de changements sur le dépôt git toutes les 5 minutes)
• exécute les tests et build les paquets debian dans la foulée
• notifie les résultats de build par mail à l'auteur du dernier commit de la branche

Jobs classiques (déprécié)¶

• créer un jenkins.sh dans chaque projet
• utiliser uniquement tox pour organiser les tests, pylint, génération de la doc, etc..
• si plusieurs suites de tests utiliser merge-junit.sh et merge-coverage.sh du projet authentic2
• ne pas activer l'option "envoyer des emails aux personnes qui ont cassé le build" pour les projets tiers
• configurer un build par scrutation du git + un build périodique (@daily, utile pour détecter au plus tôt des problèmes avec des mises à jour de dépendance)
• ne pas configurer les jobs "-deb" avec une scrutation de gir, les configurer pour constuire après le build du projet
• pour tester les branches de développement il suffit déclarer un "branch specifier" avec un wildcard, ex.: wip/*, attention si cela affecte le statut je job quelque soit la branche, il vaut donc mieux le faire sur un job spécifique (nommé par exemple <project>-wip-branches)