Il n’est pas instantané et très handicapant pour l’évolution des projets…
des fois il faut 3 PR/3jours/3semaines(si on a rien a foutre dans nos vies) pour ajouter/supprimer un espace avant/apres un « . »
c’est vraiment de la merde!
1 « J'aime »
euhhh ok,
peux tu préciser ta pensée stp ? autant pour toi et dans ton attitude de « colère » : ça doit avoir du sens.
Autant pour les lecteurs de ton post : on, a aucune idée de quoi tu parles
C’est pour une qualité du code justement pour éviter des styles trop différent. Il suffit d’utiliser un logiciel compatible PSR2, c’est plus facile ensuite mais la dernière fois, j’ai quand même eu 5PR pour une erreur travis
L’outil qui vérifie les PR sur github
1 « J'aime »
plugin for Notepad++?
Je n’utilise que ce logiciel …
Bonjour,
Dans ce cas désolé, il n’y a pas de solution avec Notepad++ pour le PSR2 à ma connaissance. Depuis 8 mois, j’utilise PHPStorm qui te permet d’utiliser le langage et la norme désiré.
Il faudrait voir du côté d’atom peut être, c’est l’outil proposé par github, il est gratuit mais je ne peux pas t’en dire plus…
Bon courage.
Salut
Basé sur Atom, il y a « Visual Studio Code » de Microsoft ! Gratuit
@+
Edit : existe pour linux aussi je crois
Je suis passée à phpstorm après plusieurs années d’ultra-edit et même si il s’agit d’un éditeur payant c’est une vrai bonheur de travailler dessus (en particulier avec Symfony, je me demande si on peu réellement coder avec ce framework en dehors de cet éditeur).
Pour en revenir à Travis, j’ai moi aussi beaucoup pesté contre lui à une certaine époque… à présent je fait plus attention à ma manière de coder, la contrainte amène bien souvent la créativité…
Bonjour 
Cela veut dire que vous déposez vos code sur Github en privé (je pense) et faites vérifier par Travis?
non, c’est pas exactement comme ça que ça fonctionne : lis leur doc (ça part d’un bon sentiment, même si je comprend maintenant le côté « frustrant » que ça peut avoir pour les dev)
Merci
je m’interresse bcp a travis/github depuis un p’tit bout de temps (pour mon compte perso )et l’idée me séduis mais ce que je comprends pas c’est le prix 
: https://travis-ci.com/plans 69$ pour des repos privés.
Après pour Dolibarr c’est open source donc pas de soucis c’est gratuit 
et efficace.
A titre d’info, j’ai mis en place sur mon environnement de dev un serveur jenkins, totalement gratuit qui permet de vérifier non seulement les PSR mais aussi la qualité du code et d’autres joyeuses choses.
2 « J'aime »
@defrance
il est amusant (de mon point de vue, et malgré des connaissances assez avancées en info/prog/admin) de lire une phrase sans y comprendre un traître mot, mais de malgré tout la trouver utile
1 « J'aime »
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 
6 « J'aime »
Voici des explications fort intéressantes.
Au point qu’elles méritent une place sur le wiki. 
Par exemple pour compléter cette page. https://wiki.dolibarr.org/index.php/Outils_de_développement
J’apprends la solution du travis local. A priori, ça semble du lourd, donc pour quelqu’un qui est en permanence sur le truc, pas pour de l’occasionnel.
Je pense qu’il faut des solutions intermédiaires, comme les éditeurs cités précédemment.
En effet, je vais essayer de voir pour compléter la page
J’aimerai également voir pour expliquer comment déployer Dolibarr en utilisant Docker pour le développement sur le Wiki. J’en profiterai pour détailler comment exécuter PHP_CodeSniffer et les tests en local (sans aller jusqu’à déployer une pile Travis-CI en local, c’est déjà d’une grande aide vu que 80% des erreurs de l’intégration continue vient du « Code style » non respecté).
C’est également possible de configurer PHPStorm par exemple pour signaler les erreurs de « Code style » en utilisant PHP_CodeSniffer et un fichier de règles comme Dolibarr en fournit un. Je vois pour documenter tout ça.
Bonjour
Hier j’ai donc installé sur mon pc Atom avec php_codesniffer (PSR2) pour info sur un de mes fichiers pris au hasard j’ai 1684 erreurs 
.
J’ai toujours fait au mieux dans mes fichiers (syntaxe, espaces, casse, etc). Ce fameux php_codesniffer me file un bon coup demain à tout corriger, à prendre les bonnes habitudes, avoir un code nickel je sais pas…mais bien moins pire oui 
Bien vu pour le wiki
@dolibarr95 attention, Dolibarr n’utilise pas la PSR2 direct mais un standard personnalisé. Tu peux configurer PHP_CodeSniffer en utilisant le fichier de règles fourni avec le code de Dolibarr ici : https://github.com/Dolibarr/dolibarr/blob/develop/dev/setup/codesniffer/ruleset.xml
Depuis le répertoire principal :
phpcs -s -p -d memory_limit=-1 --extensions=php --colors --tab-width=4 --standard=dev/setup/codesniffer/ruleset.xml --encoding=utf-8 --runtime-set ignore_warnings_on_exit true .Tu peux également rajouter l’option -n pour n’afficher que les erreurs et pas les avertissements
1 « J'aime »
Déjà que j’ai mis la journée a réussir à faire tourner tout ça correctement sous windows le personnaliser va me prendre la semaine
Si tu utilises https://atom.io/packages/linter-phpcs tu peux paramétrer un chemin vers un fichier ruleset.xml personnalisé dans les préférences du plugin.
Mais bon, c’est vrai que Windows pour développer … bof
J’préfères GNU/Linux mais bon, j’suis pas très objectif
1 « J'aime »
