ci: ajoute une action commitlint

[slafayIGN]

Je propose l'ajout d'une action commitlint à chaque push pour renforcer la cohérence des messages de commit.

Référence : https://www.conventionalcommits.org/en/v1.0.0/

Il reste à se mettre d'accord essentiellement sur les types de commits. J'ai copié la liste d'un autre projet open-source mais la liste me semble avoir des redondances ou des types dont nous n'avons pas l'usage :

• feat : nouvelle fonctionnalité pour l'utilisateur (pas une nouvelle fonctionnalité dans un script de build)
• fix : correction de buf pour l'utilisateur (pas de correction de bug dans un script de build)
• docs : changements dans la documentation (docs, README, CONTRIBUTING...)
• style : formatage, point-virgules ou accolades manquantes... sans autre changement fonctionnel
• refactor : refactoring du code, renommages de classes, fonctions, variables...
• test : ajout de tests manquants, refactoring des tests sans autre changement fonctionnel
• chore : mise à jour de tâches npm, grunt... sans autre changement fonctionnel
• ci : changements dans la configuration des github actions et workflows, pourrait être considéré comme chore
• build : me semble redondant avec chore ou ci
• config : configuration de l'application elle-même et pas des scripts de build
• norelease : me semble inutile tant que semantic-versioning n'est pas branché derrière
• breaking : me semble inutile tant que semantic-versioning n'est pas branché derrière, surtout que conventional commits propose plutôt d'utiliser la notation BREAKING_CHANGE en footer du message de commit

L'intérêt de commitlint serait de pouvoir brancher ensuite la publication automatique de releases et packages : https://github.com/semantic-release/semantic-release

[mborne]

@slafayIGN je suis partant pour qu'on essaye ce niveau de rigueur.

Par contre, preneur d'un lien "Contribuer" dans le README.md