💡 [REQUEST] - Ajouter une validation commitlint côté CI (le hook git n'est pas suffisant)

[shikanime]

Description

Le hook commit-msg Husky (.husky/commit-msg → pnpx commitlint --edit) fonctionne correctement : il rejette bien les messages non conformes au conventionnel lors d'un git commit local (vérifié en conditions réelles, code 1 sur message non typé).

Cependant, cette validation n'est exécutée que côté client. Rien n'empêche côté serveur qu'un message non conventionnel atteigne une PR : tout commit créé en dehors du chemin du hook git (outils tiers, interface non git, rebases/imports distants) passe sans contrôle. Le workflow job-lint.yml ne lance que ESLint et ne valide pas les messages de commit.

Conséquence : des messages non conventionnels arrivent dans les PRs et dans l'historique, ce qui fragilise le versioning automatique (Release Please) et la génération de changelog.

PRs liées

N/A

Issues liées

N/A

Exemples simples

N/A

Spécifications techniques

Ajouter une étape de validation des messages de commit dans la CI, exécutée sur les PRs, indépendamment du hook client :

• Ajouter un job (ou une étape dans job-lint.yml) lançant commitlint sur la plage de commits de la PR, par exemple via @commitlint/action ou un script pnpm dédié (ex. commitlint --from "origin/main" --to HEAD).
• Ne pas casser les PRs historiques : limiter la validation aux commits ajoutés par la PR (plage origin/main..HEAD), pas à l'historique complet.
• Conserver le hook Husky côté client comme retour rapide, la CI devenant le garde-fou incontournable.
• Réutiliser la config existante commitlint.config.cjs (extends @commitlint/config-conventional + règle body-leading-blank).

Définition du fini

• Une étape CI valide les messages de commit de la PR
• La validation ne s'applique qu'aux commits de la PR (plage origin/main..HEAD)
• Un PR avec un message non conventionnel est bloqué par la CI
• La config commitlint.config.cjs existante est réutilisée sans duplication
• La documentation (CONTRIBUTING.md) mentionne la validation CI