CI
Gitlab est une plate-forme d’intégration continue
L’intégration continue est une méthode de développement de logiciel DevOps par laquelle les développeureuses intègrent régulièrement leurs modifications de code à un référentiel centralisé, (en l’occurrence les dépôts git de chaque package composer et de chaque plugins-dist de la distribution SPIP) suite à quoi des opérations de création et de test sont automatiquement exécutées.
(Cf. https://fr.wikipedia.org/wiki/Intégration_continue)
Gitlab s’appuie sur une architecture distribuée de « Runners », qui exécuteront des Pipelines, des Jobs, décrits dans une spécification au format YAML, versionnée à la racine de chaque dépôt Git.
Les runners GitLab s’appuient sur Docker. La première opération est donc de télécharger ou de mettre à jour une image docker, puis d’exécuter des scripts, ordonnancés de manière plus ou moins complexe et de récupérer les retours (« reports ») que ces scripts auront générés dans un format spécifique à GitLab, pour aider les développeureuses à la revue de code, à la prise de décision, voire conduire à une autre action automatique, comme, par exemple, un déploiement.
SPIP a besoin de PHP pour effectuer différents type de tests, il est donc possible de s’appuyer sur l’image Docker officielle de PHP pour exécuter ces opérations.
Les types de tests sont, à ce jour, les suivants :
- Vérification de la syntaxe PHP (php-parallel-linter ou
php -l
) - Analyse statique (phpstan)
- Respect de règles de codage (easy-coding-standards)
- Tests unitaires (phpunit)
Il peut aussi être jugé utile de vérifier le bon comportement du code de SPIP à l’aune de ces outils en les exécutant dans un contexte ou la version de PHP va varier de la version supportée « min » à la version supportée « max ».
Les outils qui exécutent ces tests et génèrent les reports doivent être présents dans le container. Le code du dépôt Git ainsi que ces outils nécessite parfois plus que simplement PHP et parfois du paramétrage.
Ces opérations doivent donc être effectué à chaque fois que cela est nécessaire, par exemple :
- commit dans une branche soumise à « Merge Request »,
- merge de cette branche dans la branche par défaut du dépôt git testé
L’image officielle PHP « de base » fournit une version PHP, ciblée avec un tag docker (attention, le concept de tag dans docker est différent de celui de Git) et repose sur une installation Debian, en héritant de l’image officielle Debian.
Toutes ces tâches sont répétées à chaque déclenchement du pipeline de CI.
spip/tools
Tout comme l’image officielle de PHP s’appuie sur l’image officielle Debian, il est possible de s’appuyer sur une image officielle PHP (puisqu’en fait, il en existe plusieurs, celle basée sur Debian étant, en quelque sorte, celle proposée par défaut) pour produire une image dédiée aux tests de SPIP et faire appel à cette image plutôt qu’à celle de PHP et d’y exécuter l’installation d’extensions PHP supplémentaires, etc.
alpine
C’est une distribution Linux ultra légère, idéale pour les opérations de CI.
Plus légère, son poids permet une réduction du traffic réseau lors de son téléchargement et de ses mises à jours, d’un part. Elle est « décompressée » dans l’instance Docker du Runner Gitlab beaucoup plus vite.
La communauté PHP fournit une image officielle du langage basé sur alpine, avec les même features de base que celle basée sur Debian
composer et extensions PHP
On peut ajouter et configurer composer, installer des extensions PHP dans une image basée sur PHP.
Outils de dev
Si des outils de dev sont référencés dans la clé « require-dev » d’un fichier composer.json, la commande composer install
va installer ces outils dans le dossier vendor/.
On peut ensuite exécuter les outils depuis les raccourcis que composer installe dans vendor/bin
.
On peut aussi externaliser les outils, ce qui est parfois recommandé par les mainteneurs de ces outils. Outre l’avantage de ne pas influer sur le « dependency hell », ce choix influe aussi sur le traffic réseau et la taille du dossier vendor lors des opérations de tests en CI
Pilotage d’outils de dev externalisés
Si des outils de dev PHP peuvent être installés dans un dossier vendor/, ils peuvent aussi être installé « globalement » sur un système, par exemple :
composer global require --dev phpstan/phpstan
installe l’outil phpstan dans le dossier $HOME/.composer/vendor
du user unix qui lance la commande. Ce dossier, s’il est intégré dans une image docker et que le PATH Unix du user contient $HOME/.composer/vendor/bin
, l’outil phpstan est accessible depuis n’importe quel emplacement dans l’image sans qu’il soit nécessaire d’exécuter composer install
au préalable.
Il peut en aller de même pour tout autre outil, PHP ou non. Exemples:
- php-parallel-lint
- phpunit
- etc.
Mais aussi git et unzip, pouvant être nécessaires à composer selon les circonstances.
Ainsi, chaque test peut-être exécuté sans que l’outil soit requis par la lib testée. Seul sa configuration peut être versionnée.
Dilemme : un·e dev peut-il coder des tests et les exécuter sur sa machine ?
- Il est possible d’installer docker et une image telle que décrite ci-dessus puis d’utiliser cette image pour exécuter les tests localement.
- Il est possible de référencer les outils de dev PHP dans composer.json et de procéder à l’installation sur sa machine
- En corollaire, il est possible de ne pas installer les outils de dev (composer install --no-dev) lors de l’exécution d’un pipeline Gitlab et d’utiliser les outils externalisés à la place, dans un soucis de performance, ou d’écologie.
Enfin, il est aussi possible de mettre en place des « raccourcis système » dans une image Docker afin de faciliter à la fois, la vie des développeureuses, pour leur travail en local, et la rédaction des scripts d’exécution du pipeline Gitlab, par exemple avec l’outil make et un descripteur de tâches Makefile.
Ce genre d’image est maintenue depuis 5 ans sur github, utilisée pour le plugin « supported-versions » (qui sert à produire les pages semi-automatiques de suivi des versions maintenues de www.spip.net), depuis sa création.
Elle a été testée sur des composants spip-league/*
Hébergement et suivi des images Docker
L’image spip/tools est développée sur github.com afin de profiter de certains automatismes que la plate-forme Gitlab de la communauté ne fournit pas.
Le Dockerfile qui sert au build est « paramétrable » et un script shell génère les commandes de build et de push vers hub.docker.com. C’est à effectuer manuellement sur une machine de dev. L’image est disponible pour plusieurs versions PHP et les architectures système AMD64 et ARM64
Il est possible que dans le futur, les étapes de build et de push docker soient entièrement automatisées, soit via une action github, soit avec Docker Build Cloud.
D’autres images sont disponibles, une avec apache+le module php, une avec php-fpm, qu’il faut coupler avec un serveur web disposant du protocole de communication fastcgi, par exemple nginx, ou caddyserver ou apache+le module fcgi. Elles peuvent être maintenues ou mises de coté au profit de ddev pour les développeureuses.
Il sera aussi possible de fournir des images dites « auto-porteuses », c’est-à-dire prêtes à l’emploi dans un environnement de production, avec le code d’une version de SPIP donnée (stable ou beta, par exemple).
Sécurité
Le service Docker Scout analyse les images afin de déterminer leur degré de sécurité.