Discussion :

[kevin254kl]

Bonjour à tous.

Une petite question qui touche un peut à la ci mais surtout à git.
Vaut-il mieux run les outils de qualité en pré commit (test, lint) ce qui permet d'épargner la ci, et de lancer tout de même la ci pour valider après.
Ou alors de faire directement en ci puisque de toute façon ça doit passer par là..

Je me pose la question car une personne ma dis que c'était une mauvaise pratique d'utiliser le pré commit.

Merci

[Obsidian]

Bonjour,

C'est difficile de te donner une réponse précise hors contexte car, comme c'est souvent le cas avec Git, cela va dépendre en grande partie du type d'application que tu développes et du langage que tu utilises. En particulier, le fait d'utiliser soit un langage compilé, soit un langage interprété, va beaucoup influer sur la « continuité » de l'intégration et de la distribution de ton travail. Par conséquent, je ne sais pas qui t'a dit que le « pre-commit » était une mauvaise chose, mais si ça l'est, ça ne l'est que dans un contexte donné (ou alors, c'est considérer les codeurs comme des singes dont la rentabilité est mesurée aux nombres de lignes effectivement intégrées par jour, auquel cas il faut fuir).

L'idée générale est d'éviter absolument ceci : https://xkcd.com/1296/ . Au contraire, l'usage est de préparer une série de commits propres, logiquement indépendants des autres si possible (pour pouvoir éventuellement en exclure certains au besoin) et proprement documentés, pour qu'il soient facilement explorés et examinés par ses pairs, et même par soi-même quand il s'agit ensuite de se replonger dans du code très ancien ou d'identifier la révision qui a introduit un bug intermittent (avec git bisect, par exemple). Cela se fait généralement en préparant une branche jusqu'à ce qu'elle soit propre et en la proposant à l'intégration via une pull request.

En ce sens, tout ce qui peut t'éviter d'avoir à reconstruire tes commits est bienvenu et disposer d'outils de contrôle préalable est une très bonne chose… à condition qu'ils restent consultatifs ! Les outils qui imposent une marche à suivre sont une plaie parce qu'ils ne sont jamais parfaits (ni à jour) et que quand ils se trompent, ils obligent le développeur à faire des contorsions assez sales pour les contourner. Malgré cela, quand on a la main sur ces outils, il ne faut surtout pas s'en priver.

L'exemple-type est la modification d'un format de fichier, par exemple en passant, pour les fichiers texte, du format UNIX (fins de ligne en LF seul) au format Microsoft (CR LF) ou vice-versa. Ça a l'air d'une petite manip' complètement transparente qui se fait en une opération dans son éditeur mais en réalité, elle impacte par définition toutes les lignes d'un fichier. Quand ensuite on passe ça à Git, on voit un différentiel sur l'intégralité du contenu et on introduit un effet « d'horizon » dans l'historique : plus moyen d'utiliser facilement « git blame », par exemple, puisque toutes lignes sont marquées comme modifiées à cet instant précis.

Il n'est pas obligatoire d'utiliser de tels outils (la plupart des développeurs s'en tiennent à VIM) mais les ignorer volontairement en comptant sur la phase de CI, c'est un peu comme dire « vas-y, écris tout en une fois, je te dirai à la fin si c'est ce que je veux ou pas ». C'est le meilleur moyen pour avoir à tout recommencer plusieurs fois de suite.

[cavo789]

Bonsoir

Au boulot, nous avons des projets communs (=plusieurs développeurs) où nous avons mis en place tous ces contrôles côté serveur afin, entre autre, de s'assurer que le contrôle se fasse bien et d'une façon uniforme. Il en est effet possible qu'un développeur moins regardant supprime certains contrôles ou n'en fasse pas.

Ceci permet aussi de ne pas bloquer le développeur le temps que les tests soient exécutés.

A titre perso, je n'aime pas recevoir des mails de retour "Commit refusé", c'est frustrant je trouve. Perso, je lance tous mes checks sur ma machine, en pre-commit mais en fait, le plus souvent, manuellement (j'ai créé un script qui me lance les checks les uns après les autres).

Cela me permet aussi de voir en temps réel le code qui est passé à la moulinette et qui est "refusé/amendé" (je pense à rector p.ex.). Je vois réellement mes lignes de codes et je vois la correction proposée ==> j'apprends en même temps ("Ah oui, c'est vrai, je devrais plutôt faire comme ceci...").

Je peux aussi être plus strict pour certains contrôles (p.ex. Psalm ou PHPStan).

Je suppose, donc, que la réponse à ta question est variable, selon les projets et les développeurs.

Je dirais donc : faire les deux mon capitaine.

Bonsoir.

[kevin254kl]

Bonjour à vous deux,

Merci beaucoup pour vos réponses très bien expliqué
J'y vois plus clair, peut-être qu'imposer le check au pré commit est un peut rude et peut mettre du temps, je vais partir sur une commande makefile que le dev peut lancer ou non et le check en ci obligatoire.