Bonjour, nouvel article post-devcamp de Lyon … comment je me suis enfin mis à utiliser phpstan pour débusquer les bugs de mes modules dolibarr. À priori quand j’ai posé la question durant le devcamp la réponse était assez brouillon pour que je me dise que ça pourrait intéresser du monde de savoir comment faire …
ça se passe ici PHPStan pour les modules Dolibarr – Cap-REL*
Nouvel article aujourd’hui à propos de l’intégration continue dans gitlab:
Hello,
Selon moi le contrôle du code doit se faire avant de pusher le code sur le dépôt.
Je suis plutôt adepte de lancer ça en local avec un pre-commit hook dans git, qui va empêcher de pusher du code avec des erreurs.
Cela n’empêche pas d’avoir un runner gitlab qui refait un contrôle avant un deploiement du code.
J’utilise devenv pour gérer mes hooks Pre-Commit Hooks - devenv
Bien entendu, c’est pour ça que j’indique dans l’article que j’ai un fichier de conf différent spécial pour les tests gitlab …
Mais par contre dans l’article suivant lorsque je vais aborder la question de lancer les tests sur 6 versions différentes de PHP ça risque de devenir compliqué de faire faire ça au développeur sur sa machine 
avant de faire sont push…
Pour avoir la version de php que je veux, j’utilise GitHub - loophp/nix-shell: Nix shells for PHP development avec https://direnv.net/
Du coup en local, je pourrais faire un pre commit hook qui s’executerait successivement avec différentes versions de php de manière très simple.
très bon ça !!! je découvre !!! allez hop (oups c’est une expression qui n’a rien à voir avec votre pseudo) j’ajoute ça dans ma liste des choses à creuser/voir/installer/utiliser/promouvoir/etc.
Et avec quelques pirouettes de plus on peut imaginer aussi relancer sur X versions de dolibarr … perso c’est le genre de choses que je préfère laisser au serveur de build / vérification plutôt qu’à mes dev mais c’est lié à mon expérience communautaire / collaborative (ou il est délicat de demander à tous les dev d’avoir des config de tueurs pour lancer tous les tests) … et où c’est donc un frein aux contributions
Avec devenv une fois la configuration de dev définie, il suffit de partager la config et tout le monde peut installer un environnement de dev strictement identique.
Et pour chaque projet on peut avoir un environnement spécifique.
(et si on utilise NixOS comme distribution linux tout cela devient encore plus simple)
J’ai par exemple plusieurs versions de php qui tournent en local sans aucun problème en localhost.
Par exemple dolibarr avec php 7.3 et 8.2 dans deux fenêtres de firefox (j’ai mis deux fenêtres cote à cote pour la copie d’écran, mais sinon c’est dans deux onglets).
C’est le même code source de dolibarr, il me suffit de changer le sous domaine phpXX de localhost pour changer de version de php
C’est sûr, je ne dis pas que ce n’est pas possible, mais je dis que c’est délicat de demander ça aux développeurs
On peut aussi configurer un fichier Makefile pour faciliter le lancement des tests en local et utiliser ensuite la commande make
Par exemple pour un de mes projets avec symfony
SHELL := /nix/store/wllx077cz9z34zgrhwj2fc8r5r1hn6mx-bash-5.2-p15/bin/bash
.PHONY: help install fixtures tests
.DEFAULT_GOAL = help
help:
@grep -E '(^[a-zA-Z_-]+:.*?##.*$$)|(^##)' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[32m%-10s\033[0m %s\n", $$1, $$2}' | sed -e 's/\[32m##/[33m/'
vendor: composer.json ## Installe le dossier vendor
composer install
composer.lock: composer.json
composer update
install: vendor composer.lock
cache: ## Vide les caches
php bin/console cache:clear --env=test
php bin/console cache:clear --env=dev
tests: tests-init ## Lance tous les tests
php -dmemory_limit=2G bin/phpunit --stop-on-failure --stop-on-error --testdox
tests-init: ## Préparation environnement de test
php -dmemory_limit=2G bin/console cache:clear --env=test
php -dmemory_limit=2G bin/console doctrine:schema:drop --force --env=test
php -dmemory_limit=2G bin/console doctrine:schema:create --env=test
php -dmemory_limit=2G bin/console doctrine:fixtures:load --no-interaction --env=test
coverage: ## Rapport de code-coverage
php -dmemory_limit=2G bin/console doctrine:migrations:migrate --no-interaction --env=test
php -dmemory_limit=2G bin/console doctrine:fixtures:load --no-interaction --env=test
php -dxdebug.mode=coverage vendor/bin/simple-phpunit --coverage-html public/coverage-report/
stan: ## Analyse statique de code
php -dmemory_limit=2G vendor/bin/phpstan analyse src
cs: ## Analyse standard de codage
tools/php-cs-fixer/vendor/bin/php-cs-fixer fix -v --dry-run
csfix: ## Analyse standard de codage avec auto correction
tools/php-cs-fixer/vendor/bin/php-cs-fixer fix -v
Avec make tests je lance les tests, make stan je lance phpstan etc
Petite vidéo démo pour montrer comment cela fonctionne
Dans le terminal à gauche je me trouve dans /home/dev/TMP et à droite dans /home/dev/TMP/dir1
J’édite le fichier dir1/.envrc dans lequel je choisi une version de php qui va s’installer uniquement dans ce répertoire et ne sera pas disponible en dehors.
Au départ php n’est disponible nulle part, ce qu’on constate avec la commande php --version
Après l’installation ou plutôt la mise à disposition de php dans le répertoire /home/dev/TMP/dir1 on constate que dans /home/dev/TMP php n’existe toujours pas comme prévu.
<attention c’est vendredi>
Moi ce que j’aime bien c’est que ça fait d’autant plus d’arguments pour expliquer qu’il faut coder sous linux 
</troll inside>
antitroll: ça doit pouvoir marcher aussi avec d’autres os donc c’est tout à fait intéressant tout ceci !
je suis en plein dans mon dernier article j’essaye de le terminer et ensuite je creuse les idées que ça me donne, je ne sais pas si j’y passerait vraiment mais c’est toujours très intéressant (pour les versions de php, j’ai plus l’habitude d’avoir x versions de php d’installées sur mon pc ça cohabite très bien) …
en ce moment j’ai php5.6 php7.3 php7.4 php8.0 … 8.3 vive https://deb.sury.org/
J’ai ça aussi, direnv c’est uniquement pour la version CLI de php, sinon pour php-fpm j’ai plusieurs versions également
Petit lien Devenv: Compose a Developer Environment easily for PHP with Nix | Shyim's Brain
hello
juste pour annoncer que je travaille en ce moment sur un tuto pour implémenter phpstan avec jenkins (et d’autres outils de d’analyse comme phpmd, ou phpcs) dans un docker
L’idée étant d’avoir à chaque commit un test de mon module, avec un retour d’anomalie et la création du zip (bon ca c’est pour qd on aura un nouveau dolistore…)
L’avantage c’est de pouvoir lancer automatiquement les tests et d’avoir de jolies graphiques
super !
plus il y aura de docs et mieux ça sera pour couvrir le maximum de cas d’utilisation … de mon côté je m’appuie de plus en plus sur gitlab mais jenkins a été mon assistant préféré pendant plus de 15 ans dans mon ancien projet …
et donc @defrance n’hésites pas à me solliciter si besoin à propos des stubs (voir PHP Stubs – Cap-REL* et PHPStan pour les modules Dolibarr – Cap-REL*) pour alléger le process de test avec phpstan (pour ne pas avoir à récupérer les sources de dolibarr) … de mon côté niveau optimisation j’ai aussi évité l’utilisation de docker (trop gourmand en ressources à chaque build) pour passer sur des ct dédiés.
Phpstan a a été le plus simple à mettre en place, je me suis servis de tes stubs, mais j’ai des alertes qd j’incluent les classes de mes modules dans un autre module…
Pour ce qui est de l’usage de docker, j’ai un serveur dédié et comme je suis sous windows, je n’ai pas à galérer (et je peux caler des versions différentes de mon environnement si jamais)
Là ou je galère c’est qu’habituellement j’utilisait phing pour lancer mes outils de controle or la version diffusée n’est plus tres compatible…
PS : c’est quoi un ct?
C’est bien j’en ai parlé lors du dernier devcamp et je suggère que nous publions nos stubs de nos modules pour pouvoir s’appuyer dessus lorsqu’on a des dépendances croisées intermodules … ce qui est quasi systématique avec mes modules aussi
Pardon pour les acronymes, ct = conteneur (technologie LXC, par exemple proposé en standard sur proxmox), c’est plus léger qu’une vm / docker
Ça donne ça sur un serveur de dev : un LXC par version de php et chaque LXC est sollicité pour lancer la batterie de tests sur les différentes versions de dolibarr via les stubs
