Pipeline (CI/CD)



Voir le status d'une Merge Request

A chaque fois qu’une Merge Request est modifiée (par un push), plusieurs tests sont effectués afin de s’assurer que tout est conforme aux spécification SAINet.

Merge Request statut

Attention:

Tant qu’une Merge Request a des erreurs, elle ne peut être acceptée !

L’auteur de la Merge Request est donc tenu de corriger les erreurs.


Voir les erreurs

En cliquant sur les croix rouges, on arrive sur un output (fond noir) qui donne tout le détail de ce qui a été effectué.

Voir les erreurs

Les parties du début ne nous intéressent généralement pas (c’est le build du code). Les tests sont effectués à la fin du build, les erreurs se trouvent donc à la fin du log.

Un clique sur la souris en bas à droite nous amène directement à la fin du log. Il faut remonter un peu pour voir les messages d’erreur.

Détails des erreurs

On peut voir ci-dessus que 4 erreurs ont été détectées. Le message donne toujours le contexte (customer, tâche/table, page/datapage, champ, …) afin de cibler au mieux ce qui pose problème.

Il se peut qu’il y a des messages avec le tag [WARNING] ou [INFO]. Ceux-ci n’ont pas besoin d’être pris en compte, seuls les messages de type [ERROR] doivent être corrigés.


Détails des erreurs

Les tests unitaires se font sur le paramétrage mergé selon les configurations des modules par défaut dans le fichier customers.xml. Il se peut donc que même si l’erreur indique que c’est pour le module pmi, l’erreur se trouve dans le module global. Généralement, comme on se débranche toujours du master (qui est censé ne pas provoquer d’erreur), c’est forcément une des modifications de la branche qui a causé le souci.

Les checks sont effectués pour tous les customers mentionnées dans customers.xml. Il est donc possible qu’en modifiant un module, une erreur apparaisse dans un autre module. Cela indique que vos modifications ont cassé quelque chose ailleurs.


Lancement manuel

Note:

Cela nécessite d’avoir au préalablement compilé le projet (mvn install -T 2).

Afin de ne pas avoir besoin de publier les modifications de suite, il est possible de directement lancer les tests en local en utilisant la commande suivante dans un terminal:

mvn test -pl testing/sources -P master

Cela va lancer les tests qui sont effectués dans les branches en attente d’intégration.


Une fois les erreurs corrigées

Il suffit de simplement publier à nouveau la branche (git push --force). Les tests seront relancés automatiquement à chaque fois que des modifications sont publiées.