Bonjour,
Je commence à tester et mettre en place des CI,
- d’abord sur le groupe spip-league,
- puis viendra le groupe spip.
Explications
Ces CI restent simples dans un premier temps et concernent le code PHP.
On les applique sur la branche principale & les PR (ça se règle dans un fichier .gitlab-ci.yml tout ça). Elles vérifient
- que le code PHP est valide (lint),
- que le dépot peut se construire (composer install),
- qu’il n’a pas de faille de sécu connu sur les libs composer déployées (composer audit)
- que le code est bien formaté (coding standard)
- que les tests unitaires s’exécutent sans erreur (phpunit)
- que le code source est bien testé partout (code coverage avec phpunit)
- qu’il n’y a pas d’erreur d’analyse statique (avec phpstan)
Et c’est déjà pas mal pour un début.
Et pour ce début, donc on essaie de viser assez haut pour ce qui est déplacé ou créé dans spip-league
- level max de phpstan si possible,
- code coverage proche de 100% pour les tests
Mais on ne pourra pas faire tout cela pour ce qui est dans spip/* parce que legacy, tout ça, tout ça…
Toujours est-il que du coup, lorsqu’une PR arrive, il y aura un «pipeline» qui s’exécute, avec différentes taches à effectuer, et cela va afficher des petites pastilles vertes ou rouges : et quand c’est rouge, devinez quoi : c’est que quelque chose est à corriger !
Exemple:
Détail du pipeline:
Là on voit que PHPStan retourne une erreur sur le code (qui n’est pas dans son fichier de baseline : c’est à dire que c’est une nouvelle erreur donc), soit il faut la corriger (le mieux si possible), soit l’ajouter à sa baseline.
Il y a des rapports générés (au format json) que comprends Gitlab, et qui peuvent aussi être téléchargés.
Test unitaires
Et justement pour les «test unitaires», il faudra pour spip/ecrire/tests qui contient différents jeux de tests de l’application SPIP et pour certains plugins-dist adapter cela : actuellement une partie voire la plupart sont plus des «tests fonctionnels» que des tests unitaires : ils ont besoin que l’application SPIP soit fonctionnelle (base de données déployée avec du contenu, config/ présente), et ce ne sont donc pas a proprement parler des tests unitaires (qui ne nécessitent que le dépôt git et le vendor/ associé pour fonctionner). Certains tests pourront certainement être transformés, mais pas tous…
Tout cela pour dire que la CI sur spip/ecrire n’exécutera pas ses tests phpunit dans un premier temps.
Optimisations
Les CI peuvent être optimisés de différentes manières : la plus simple étant de ne pas faire exécuter certains jobs si le job précédent a échoué.
Dans .gitlab-ci.yml · main · spip-league / cache · GitLab par exemple il y a plusieurs termes pour cela :
job:test:php-8.2:
stage: test
needs:
- job:test:php-latest
when: on_success
when: on_success: le job n’est pas exécuté si le « stage » (l’étape) précédent a échoué (lesstageétant déclaré tout en haut du fichier)needs: ...: le job n’est pas exécuté si le job indiqué a échoué
L’idée c’est d’éviter de lancer des jobs si certaines étapes échouent.
On pourra aller plus loin également (c’est ce que voulais faire James et il avait commencé comme cela) en fournissant une image docker toute prête, avec les outils qu’il faut pour analyser dedans, et donc au lieu de mettre image: php:lastest et de compléter l’image dans before-script: avec ce qui nous manque, il y aurait une image existante directement à télécharger, ce qui serait un peu plus rapide et efficace pour les CI, mais nécessite donc de maintenir une image docker spécifique à côté aussi. Bref, on n’en est pas là non plus.
Recherche de Runners
C’est bien joli tout ça, mais il faut des machines derrière !
Les CI nécessitent des « Runners », déclarés à notre Gitlab : en gros des ordinateurs ou serveurs qui ont installé et configuré un « Gitlab Runner » (de type docker), et exécutent des taches (job) à la demande, lorsque ces machines sont allumées.
Actuellement on a déclaré 2 machines locales (pas des serveurs), donc qui ne sont pas tout le temps allumés. La machine contenant le Gitlab (git.spip.net) ne peut pas être utilisée à cela (c’est fortement déconseillé de mettre les runners dessus).
Donc : si qqn·e de la communauté veut proposer un serveur, ou une machine locale même, ça sera certainement bienvenu car la charge des CI peut vite devenir importante.
Voilou pour ce petit résumé.
, bah c’est pas si simple !
à toustes quand même