Il est clair que je ne suis pas le premier avec cet objectif de mettre des hook sur mes repository SVN.

Je vais donc reprendre ici ce que j'ai trouvé ailleurs et juste expliquer mes choix et modifications.

J'ai trouvé ceci "Utilisation des hooks avec suversion".

On y trouve l'exemple suivant à placer en pre-commit

[bash]
#!/bin/bash

#récupération du path du repository
REPOS="$1"

#récupération du nom de la transaction
TRANS="$2"

# Définition des paths des différents binaires
SVNLOOK=/usr/bin/svnlook
PHP=/usr/bin/php


# Pour chaque fichier modifiés
for FILE in $($SVNLOOK changed -t "$TRANS" "$REPOS" | cut -b 5-); do

  #on vérifie que le fichier se termine bien par une extension php
   if [ "${FILE: -4}" == '.php' ]; then
 
      # on récupère le contenu du fichier et on analyse sa syntaxe
      # avec la commande "php -l"
       $SVNLOOK cat -t "$TRANS" "$REPOS" "$FILE" | $PHP -l

       # On regarde le code exit d execution de la commande PHP
       if [ $? != 0 ]; then
           # On sort en cas d erreur
           echo "Transaction annulée: des erreurs PHP sont présentes dans le fichier $FILE" 1>&2
           exit 1
       fi
   fi
done

# tout est bien passé on peut committer
exit 0

Il existe 2 sortes de hook.

les post- et les pre-

Généralement on envisage le pre- puis on se dit non dans l'urgence on doit pouvoir le faire donc on mets en Post-

Personnellement la solution que j'apprécie c'est le pre-commit bloquant qui peut être débloqué par un message spécial dans le commentaire.

Scénario, Je veux forcer les développeurs à commiter du code php valide E_ALL avec le script ci-dessus.

Problème je dois commiter volontairement un bout de code qui ne passe pas E_ALL mais qui fonctionne.

Je vais donc prévoir un "tag" qui permet d'overrider ce contrôle pour "accepter" le commit. Grâce à cela, je sais que c'est un acte volontaire et réfléchi. Je peux donc exiger des explications pertinentes.

Donc si le tag est utilisé, j'exigerai une explication dans le mail, et je vais déclancher un mail "spécial" pour avertir le responsable qualité qu'une entrave à la règle a été demandée. S'en suivra l'exigence d'une réparation dès que le rush est passé.

Voyons maintenant les "hooks" que je voudrais ajouter.

• Interdire les commentaires vides
• Interdire le php qui ne pass pas php -l
• Envoyer un mail au commit
• Modifier le statut des tickets Trac
• déclencher les tests unitaires
• valider le xml
• vérification du charset
• appliquer des règles de codages
• vérifier le respect des règles de codage
• regénérer la documentation
• vérifier la couverture de la documentation
• phpCodeSniffer

Sur kitpages

J'ai

• Interdire les commentaires vides

et j'en ai d'autres sur le site de subversion

à suivre...