Implémenter des hooks Git
La priorité accordée à la qualité du code dans le processus de développement doit commencer par l'élaboration du code local. Il est important d'identifier les opportunités de cette pratique avant même de commencer les demandes de tirage afin de détecter et de rectifier les problèmes potentiels de qualité du code.
Les crochets Git offrent une grande opportunité. Ils servent de mécanisme d'exécution de scripts personnalisés en réponse à des événements importants du cycle de vie de Git, tels que les commits, les fusions et les pushes. Les scripts, situés dans le répertoire .git\hooks du dépôt, offrent une flexibilité pratiquement 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 hooks 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 but, mais les empêche également de fonctionner. 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 sample
de pré-validation en pré-validation. Comme le nom du fichier l'indique, le script qu'il contient sera exécuté chaque fois que vous invoquerez l'action git commit. La validation ne suit que si le script de validation se termine avec une valeur de retour de 0.
Cependant, il est important de noter que, par défaut, cela ne fonctionnera pas comme prévu dans aucun des systèmes d'exploitation Windows. La raison souvent négligée de ce comportement est la première ligne du script :
#!/bin/sh
Sur les systèmes d’exploitation Linux, le # ! indique au chargeur de programmes que le reste du fichier contient un script à interpréter et que /bin/sh est le chemin complet de l'interpréteur à utiliser.
Bien que Git pour Windows prenne en charge les commandes Bash et les scripts shell, il ne suit pas la même convention pour désigner les chemins d'accès au système de fichiers. Au lieu de cela, vous devez indiquer le chemin d'accès complet au fichier sh.exe, en commençant par la lettre du lecteur.
Cependant, il y a une mise en garde supplémentaire, qui résulte du fait que Git pour Windows est installé par défaut dans le répertoire C:\Program Files. Comme ce répertoire contient un espace dans son nom, le chemin d'accès au fichier sh.exe serait interprété comme deux chemins d'accès distincts, ce qui entraînerait un échec. Pour l'éviter, il est nécessaire d'ajouter une barre oblique inverse (\) 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 procéder
Comment utiliser les nouvelles fonctionnalités des scripts de pré-validation Git ? Et si vous empêchiez de divulguer accidentellement des secrets sur GitHub ?
Utilisons le hook Git pour analyser le code qui est validé dans votre dépôt local à la recherche de mots clés spécifiques. Remplacez le contenu du fichier d’interpréteur de commandes 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 des mots-clés est délibérément triviale. L’utilisation d’expressions régulières permet d’étendre considérablement son champ d’application et sa flexibilité. Vous avez également la possibilité de faire référence à un fichier externe, ce qui simplifierait considérablement la maintenance courante.
Fonctionnement
Une fois invoqué, le script hook de pré-validation utilise les commandes git diff et grep pour identifier des mots-clés ou des modèles dans les modifications incrémentielles du code qui sont en cours de livraison. Si des correspondances sont détectées, le script génère un message d'erreur et empêche la validation.
Ce n’est pas tout :
D'autres cas d'utilisation courants des scripts de crochet de pré-commission incluent le formatage du code, le linting, ou l'exécution de tests personnalisés pour s'assurer que la validation respecte les normes du projet. Prepare-commit-msg s’exécute avant le lancement de l’éditeur de messages de validation. Il permet la génération dynamique de messages de validation afin d'appliquer des conventions de dénomination, telles que l'utilisation de préfixes désignés (par exemple, feat : pour les fonctionnalités ou fix : pour les corrections de bogues).
Par exemple, le script prepare-commit-msg suivant ajoute automatiquement le nom de la branche actuelle au message de livraison lors de la création d'une nouvelle livraison. Il modifie le fichier de messages de validation ($1) en ajoutant le nom de la branche suivi de 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 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 électronique du destinataire, le serveur SMTP, ainsi que l'objet et le corps du message. En outre, vous devrez peut-être configurer votre système pour qu'il envoie des courriers électroniques à l'aide de la commande PowerShell Send-MailMessage ou utiliser une méthode différente 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 convient de noter que le dossier .git\hooks du dépôt n’est pas commité dans le contrôle de code source. Vous vous demandez peut-être 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, c’est qu’à partir de Git version 2.9, vous pouvez mapper des hooks Git à un dossier qui peut être validé dans le contrôle de code source. Pour ce faire, vous pouvez mettre à jour la configuration des paramètres globaux de votre dépôt Git :
Git config --global core.hooksPath '~/.githooks'
Si jamais vous avez besoin de remplacer les hooks Git que vous avez configurés côté client, vous pouvez le faire à l’aide du commutateur no-verify :
Git commit --no-verify
Hooks côté serveur
Alors que les crochets Git côté client offrent de solides capacités pour améliorer le flux de travail de développement, Azure Repos fournit également des crochets côté serveur pour améliorer encore le processus de développement, y compris la prise en charge de la création de demandes d'extraction. Pour plus d’informations, consultez la référence des événements de hooks Azure Repos Service.