Implémenter des hooks Git
La hiérarchisation de la qualité du code dans le processus de développement doit commencer par le développement de code local. Il est important d’identifier les opportunités pour cette pratique, même avant de commencer les demandes de tirage pour détecter et corriger les problèmes potentiels de qualité du code.
Les hooks Git offrent une excellente opportunité. Ils servent de mécanisme pour l’exécution de scripts personnalisés en réponse à des événements significatifs dans le cycle de vie Git, tels que les validations, les fusions et les envois (push). Les scripts, situés dans le répertoire .git\hooks du référentiel, offrent pratiquement une flexibilité illimitée dans l’automatisation des tâches de développement logiciel et l’application des normes de développement.
Comment implémenter des hooks Git
Commençons par explorer les crochets Git côté client. Accédez au répertoire .git\hooks du dépôt . vous trouverez de nombreux fichiers avec l’extension sample
. Cette extension indique non seulement leur objectif, mais les empêche également de s'exécuter. Les noms de fichiers désignent les actions Git qui déclenchent leur exécution une fois que vous avez supprimé l’extension sample
.
Renommez le fichier pre-commit sample
en pre-commit. Comme le nom du fichier indique, le script qu’il contient s’exécute chaque fois que vous appelez l’action de validation Git. La validation suit uniquement si votre script de pré-validation quitte avec la valeur de retour 0.
Toutefois, il est important de noter que, par défaut, cela ne fonctionnera pas comme prévu dans l’un des systèmes d’exploitation Windows. La raison couramment ignorée de ce comportement est la première ligne du script :
#!/bin/sh
Sur les systèmes d’exploitation Linux, le # ! le préfixe indique au chargeur de programme que le reste du fichier contient un script à interpréter et /bin/sh est le chemin complet de l’interpréteur qui doit être utilisé.
Bien que Git pour Windows prenne en charge les commandes Bash et les scripts d’interpréteur de commandes, il ne suit pas la même convention lors de la conception des chemins du système de fichiers. Au lieu de cela, vous devez fournir le chemin complet du fichier sh.exe, en commençant par la lettre de lecteur.
Toutefois, il existe une mise en garde supplémentaire, qui résulte du fait que Git pour Windows par défaut est installé dans le répertoire C :\Program Files. Étant donné que ce répertoire contient un espace dans son nom, le chemin résultant du fichier sh.exe serait interprété comme deux chemins distincts, ce qui entraîne un échec. Pour éviter cela, il est nécessaire d’ajouter une barre oblique inverse unique (\) devant l’espace pour servir de caractère d’échappement. En effet, lorsque vous utilisez la version 64 bits de Git pour Windows, la première ligne du script doit avoir le format suivant :
#!C:/Program\ Files/Git/usr/bin/sh.exe
Comment le faire
Comment utiliser les fonctionnalités nouvellement découvertes des scripts de pré-validation Git ? Comment vous empêcher de divulguer accidentellement des secrets sur GitHub ?
Utilisons le hook Git pour analyser le code validé dans votre référentiel local pour obtenir des mots clés spécifiques. Remplacez le contenu du fichier shell de pré-validation par le code suivant :
#!C:/Program\ Files/Git/usr/bin/sh.exe
matches=$(git diff-index --patch HEAD | grep '^+' | grep -Pi 'password|secret')
if [ ! -z "$matches" ]
then
cat <<\EOT
Error: Words from the blocked list were present in the diff:
EOT
echo $matches
exit 1
fi
Cet exemple est destiné à illustrer le concept plutôt qu’une solution à part entière, de sorte que la liste de mots clés est intentionnellement triviale. En utilisant des expressions régulières, vous pouvez étendre considérablement son étendue et sa flexibilité. Vous avez également la possibilité de référencer un fichier externe, ce qui simplifierait considérablement la maintenance continue.
Fonctionnement
Une fois appelé, le script de hook de pré-validation utilise les commandes git diff et grep pour identifier les mots clés ou les modèles dans les modifications incrémentielles apportées au code en cours de validation. Si des correspondances sont détectées, le script génère un message d’erreur et empêche la validation de se produire.
Il y a plus :
D'autres cas d'usage courants des pré-commit hooks incluent la mise en forme du code, le linting ou l'exécution de tests personnalisés pour garantir que le commit respecte les normes du projet. Prepare-commit-msg s’exécute avant le lancement de l’éditeur de message de validation. Il permet de créer dynamiquement des messages de validation afin d’appliquer des conventions d’affectation de noms, telles que l’utilisation de préfixes désignés (par exemple, exploit : pour les fonctionnalités ou correctifs : pour les correctifs de bogues).
Par exemple, le script prepare-commit-msg suivant ajoute automatiquement le nom de la branche actuelle au début du message de validation lors de la création d’une nouvelle validation. Il modifie le fichier de message de validation ($1) en ajoutant le nom de la branche suivi d’un signe deux-points et d’un espace au début du fichier.
#!C:/Program\ Files/Git/usr/bin/sh.exe
# Get the current branch name
branch_name=$(git branch --show-current)
# Check if the commit message file exists
if [[ -f "$1" ]]; then
# Prepend the branch name to the commit message
sed -i "1s/^/$branch_name: /" "$1"
fi
Les scripts de post-validation s’exécutent après la fin d’une validation. Il peut être utilisé pour déclencher des notifications ou générer de la documentation.
Par exemple, le script suivant envoie une notification par e-mail à un destinataire désigné après chaque validation. Le script peut être personnalisé en modifiant l’adresse e-mail du destinataire, le serveur SMTP et l’objet et le corps de l’e-mail. En outre, vous devrez peut-être configurer votre système pour envoyer des e-mails à l’aide de l’applet de commande PowerShell Send-MailMessage ou utiliser une autre méthode pour envoyer des notifications, en fonction de votre environnement et de vos besoins.
#!C:/Program\ Files/Git/usr/bin/sh.exe
# Set the recipient email address
$recipient="your@email.com"
# Set the subject of the email
$subject="Git Commit Notification"
# Set the body of the email
$body="A new commit has been made to the repository."
# Send the email notification
Send-MailMessage -To $recipient -Subject $subject -Body $body -SmtpServer "your.smtp.server"
Il est important de noter que le dossier .git\hooks du dépôt n'est pas intégré au système de gestion de version. Vous pouvez vous demander s’il existe un moyen de partager les scripts que vous avez développés avec d’autres membres de votre équipe de développement. La bonne nouvelle est que, à partir de la version 2.9 de Git, vous pouvez associer des hooks Git à un dossier qui peut être validé dans le système de gestion de code source. Pour ce faire, vous pouvez mettre à jour la configuration des paramètres globaux pour votre dépôt Git :
Git config --global core.hooksPath '~/.githooks'
Si vous avez besoin de remplacer les crochets Git que vous avez configurés côté client, vous pouvez le faire à l’aide du commutateur sans vérification :
Git commit --no-verify
Server-Side Hooks
Bien que les gâchettes Git côté client offrent des fonctionnalités robustes pour améliorer le flux de travail de développement, Azure Repos fournit également des gâchettes côté serveur pour améliorer encore le processus de développement, notamment la prise en charge de la création de requêtes d'extraction. Pour plus d'informations, consultez la référence des événements Azure Repos hooks de service.