Même si c’est vrai que je trouve saoulant de corriger une PR soumise à chaque fois à cause de problèmes de syntaxe qui ne viennent en plus pas nécessairement des modifications de la PR en question (soit d’anciennes PR qui ont été fusionnées dans les branches alors qu’elles étaient en erreur, soit des devs de la core team qui poussent en direct dans les branches et « squizzent » donc l’intégration continue), ça reste une bonne chose et permet d’éviter que tout le monde (enfin presque) fasse n’importe quoi
Pour les personnes qui se demanderaient à quoi sert Travis CI :
Il s’agit d’un logiciel en ligne qui fonctionne avec Github.
Pour rappel, lorsqu’un utilisateur de Dolibarr souhaite intégrer des modifications qu’il a apporté au code source de Dolibarr, il lui est possible de faire une Pull Request ou PR sur Github (une Pull Request, c’est dans le « jargon » Github, une demande aux mainteneur d’un projet sur Github d’intégrer les modifications que l’on a effectué au code source dans le projet principal).
Afin de garder un certain niveau de qualité au niveau du code source d’un logiciel, il est possible de mettre en place ce que l’on appelle de l’intégration continue. L’intégration continue permet d’exécuter de façon automatique un certain nombre d’actions à chaque fois qu’une Pull Request est soumise ; par exemple :
- vérifier que le code ne produit pas d’erreurs de syntaxe à l’exécution ; pour cela, on peut utiliser par exemple phplint
- vérifier que les fichiers sont conformes à une convention de codage ou à un standard de style de code (PSR2 [en]) ; pour cela on peut utiliser par exemple PHP_CodeSniffer
- exécuter des tests unitaires et/ou des tests d’intégration et vérifier qu’ils ne retournent aucune erreur : on peu utiliser par exemple phpunit
Évidement, ces différentes actions prennent du temps à être exécutés et le sont à chaque soumission d’une Pull Request, ce qui peut expliquer l’énervement de certains … De plus, les différentes actions sont exécutées pour différentes versions de PHP et différents SGBDR (Système de Gestion de Bases de Données Relationnels) à chaque fois. Actuellement chaque Pull Request est testée avec l’ensemble de la suite d’actions (lint, phpcs, tests) pour PHP 5.5, 7.3 et nightly et pour MySQL (MariaDB et PostgreSQL.
Travis-CI est donc l’outil qui exécute ces actions de tests. Si vous êtes curieux, vous pouvez accéder aux tests de toutes les PR ici : https://travis-ci.org/dolibarr/dolibarr/pull_requests
En définitive, l’intégration continue est un passage obligé pour garantir un certain niveau de qualité sur un projet logiciel. Il est possible de la mettre en œuvre de diverses manières et en utilisant diverses solutions techniques/logicielles (j’utilise par exemple personnellement Gitlab CI qui est intégré dans Gitlab : une alternative libre/opensource à Github).
Il ne faut pas perdre de vue que l’exécution des tests consomme « du temps machine » et que c’est déjà une chance d’avoir la possibilité d’utiliser un outil comme Travis CI gratuitement pour les projets Open source tels que Dolibarr.
L’ensemble des actions exécutées sont consultables ici : https://github.com/Dolibarr/dolibarr/blob/develop/.travis.yml et il reste toujours possible de les exécuter localement AVANT de soumettre sa PR pour éviter d’avoir à la corriger ensuite suite à un échec.
Voir aussi : How to run travis-ci locally [en]
Désolé pour la tartine … j’espère que ça aura été instructif pour quelques uns