Tutorial Svn : Créer Des Hooks, Comment lancer des scripts

Pré-requis:
- Avoir un serveur dédié
- Utiliser SVN (subversion)
- Être à l'aise avec Linux, ce document est fait pour expliquer et montrer comment, pas pour dire précisément ou cliquer et quoi taper. (Ce n'est pas un Walktrought)
- Savoir faire des BACKUPS AVANT.
- Être conscient que je ne suis pas doué pour faire des tutoriels.
- La méthode présentée ici n'est pas la plus sécuritaire, mais elle est simple. À vous de bien définir les droits d'utilisateurs.

Configuration utilisée:
- Un serveur Debian (donc les serveurs Ubuntu: c'est similaire, voire identique)
- user-www est l'utilisateur de la machine qui fait tourner apache.


Intro:
Je viens tout juste de terminer la configuration de hooks afin de mettre à jour automatiquement la sandbox (version test) de mon site, et générer automatiquement la documentation PHP (avec PHPDocumentator).

Qu'est-ce qu'un hook ?
Les hooks sont des fichiers lancés par Subversion lorsqu'un certain statut est atteint.
Il existe des fichiers template dans le dossier hooks/ de votre repository:
- pre-commit.tmpl
- start-commit.tmpl
- post-commit.tmpl

- pre-revprop-change.tmpl
- post-revprop-change.tmpl

- pre-lock.tmpl
- post-lock.tmpl

- pre-unlock.tmpl
- post-unlock.tmpl

Dans le cas que j'expliquerai, nous utiliserons le hook post-commit afin de lancer certaines commandes après qu'un commit ai été fait.

Comment faire un fichier hook
Pour activer un hook, j'ai fait 3 choses:

1) J'ai copié le fichier d'exemple/template, en retirant l'extension
2) Je me suis assuré que le groupe de l'utilisateur apache ai accès au fichier (car apache lance SVN qui lance le fichier hook, donc si le fichier est root, SVN ne pourra pas y accéder)
3) J'ai rendu le fichier exécutable


Ensuite, on y met quelques actions, personnellement, j'en ai fait 3:

Ici, je me suis assuré que l'utilisateur user-www avait le droit de faire un echo. Pour vérifier cela, j'ai fait comme ceci:

# Mettre à jour la sandbox
Quelques détails sont importants à savoir:
- Les fichiers hooks n'ont pas d'environnement chargé. Donc il faut spécifier les chemins complets à chaque fois. Même si en shell "svn" est résolu correctement, ça pourrait ne pas être le cas du fichier hook, et vous n'auriez pas vraiment d'erreur, alors on met les chemins complets.
- Comme la commande requiert plus que les privilèges de user-www, il faudra donc faire un sudo devant. Par contre, on ne veut pas avoir à entrer le mot de passe sudo à chaque fois, il faudra ajouter une exception ( à venir )


# Mettre à jour le fichier contenant le # de la révision
Et la commande echo fonctionnait bien. (faites la commande "su" pour retourner en root)

Donc pas besoin de sudo devant le echo.
Par contre, il faut s'assurer que le fichier revision.txt peut être accédé par user-www:

# Générer la documentation Php Documentator:
Ici, tout comme pour la mise à jour de la sandbox, on a besoin de faire un sudo, car les commandes dans le fichier phpdoc.sh, ainsi que l'accès lui-même du fichier phpdoc.sh n'est pas possible pour user-www.



Créer les exceptions pour ne pas avoir à entrer de mot de passe pour les commandes préfixées de SUDO
Il suffit d'ajouter une exception dans le fichier /etc/sudoers
Pour se faire, vous pouvez utiliser nano (ou visudo, recommandé, si vous savez l'utiliser):

sudo nano /etc/sudoers

Et vous devez ajouter une ligne par commande préfixée par un sudo dans le fichier hook:

Chaque ligne dit environ ceci (selon ce que j'ai compris):
L'utilisateur user-www, accédé de n'importe ou (localhost ou externe), qui veut un accès root n'aura pas à entrer de mot de passe pour la commande /usr/bin...



Voilà, en gros, c'est ça


Si vous avez une erreur après votre commit qui dit malgré tout "200 OK":

, c'est qu'il y a un pépin quelque part avec votre fichier hook. Assurez-vous qu'au niveau des permissions d'accès que tout est correct.