Coding Subversion Pre Commit Hook
Geschrieben von Markus in Administration & Coding am 16.02.2011 um 17:45 Uhr.
In einem anderen Artikel habe ich bereits vor einer ganzen Weile schon über die so nützlichen SVN Hooks geschrieben, die standardmäßig bei jedem Repository mitgeliefert werden. Damals habe ich ausschließlich das post-commit Hook, also dem Script, was nach dem erfolgreichen Commit ausgeführt wird, an einem Beispiel vorgestellt.
Heute möchte ich mich dem pre-commit Script widmen. Dieses Script wird, wie der Name vermuten lässt, vor dem entgültigen Commit ins Repository ausgefürt. Wie auch beim post-commit Hook gibt es keine Grenzen in der Umsetzung. Es kann den Code auf Syntax-Fehler prüfen, den Commit verweigern, wenn der Comment nicht den eigenen Standards entspricht oder die Einhaltung der internen Programmierstandards checken.
Inwieweit diese Prüfmechanismen sinnig oder überlüssig sind, hängt ganz vom angewandten System und natürlich jedem Team selbst ab. Ich habe da meine klaren Regeln, was in das Hook gehört, und was nicht.
Die Prüfung auf Syntax-Fehler ist im Produktivsystem unverzichtbar. Was live geht, muss wenigstens vom Syntax her stimmen (von der Logik her natürlich auch). Im Developing ist das allerdings nicht so wichtig, als das eine Prüfung den Commit verweigern sollte. Ebenso ist es im Branch weniger wichtig, dass die Comment-Standards eingehalten werden. Im trunk allerdings schon, denn gerade im hitzigen Gefecht zwischen Bugs und Fixes ist es wichtig, dass irgendjemand auch nach Wochen noch durchblickt, was in welcher Revision eigentlich eingespielt wurde, ohne die History durcharbeiten zu müssen.
Anders sieht es mit den Programmierrichtlinien aus. Diese Prüfung gehört definitiv ausschließlich in den Entwicklungsbereich. In das Produktivsystem kommt so nur standardkonformer Code. Im Falle eines schnellen Bugfix direkt im Live-System, bei dem das Motto "Zeit ist Geld" zählt, sind die Richtlinien ersteinmal Nebensache.
Im Folgenden möchte ich also meine Lösung vorstellen, die die eben geschriebenen Regeln berücksichtigt und umsetzt.
Als erstes müssen wir wissen, wie der Hook arbeitet. Dazu lesen wir uns das Template durch, was im /var/svn/repo/hooks/ Verzeichnis liegt. Dort erfahren wir, dass das Script mit zwei Parametern aufgerufen wird. Zum einen die Pfade, in denen Änderungen vorgenommen wurden, und zum anderen der TXN-Name, der die temporäre Revisionsnummer darstellt.
Mithilfe dieser beiden Parameter können wir nun die genauen Änderungen mittels svnlook-Befehl rausfinden. Nun können wir alle PHP Dateien im trunk, an denen Änderungen vorgenommen wurden, mittels php -l auf Syntax-Fehler prüfen. Jede Datei muss einzeln geprüft werden, und diese Prüfung bauen wir in eine for-Schleife ein.
Das ganze Sript sieht dann so aus:
/var/svn/repo/hooks/pre-commit
Das Script sorgt dafür, dass der enthaltene Fehler direkt an den SVN-Client gemeldet wird. Man bekommt also sofort den Punkt geliefert, wo das Problem aufgetreten ist, ohne im Trüben fischen zu müssen, sofern man im Editor keine Code-Validierung angeschalten hat.
Damit die Datei nun auch ausgeführt wird, muss die die nötigen Rechte erhalten. Der Benutzer, unter dem Subversion ausgeführt wird, muss Ausführrechte erhalten. Achtung: Auch der root-Benutzer muss weitere Rechte eingeräumt bekommen. Deswegen setzen wir, um auf Nummer sicher zu gehen, die vollen Rechte:
chmod 0777 /var/svn/repo/hooks/pre-commit
Und schon ist das pre-commit Hook fertig, was dafür sorgt, dass kein Code mit Syntax-Fehlern ins Live-System gerät. Wenn man sich diese drei Minuten Zeit nimmt, um das Script in den eigenen Repositories zu aktivieren, kann man sich eine Menge Zeit und Ärger sparen. Ich habe im Jahr 2008 tatsächlich mal einen großen Teil einer sehr stark frequentierten Seite lahm gelegt, weil soein Hook nicht vorhanden war, als ich in einer Datei ein Semikolon am Ende einer Zeile vergessen habe.
Heute möchte ich mich dem pre-commit Script widmen. Dieses Script wird, wie der Name vermuten lässt, vor dem entgültigen Commit ins Repository ausgefürt. Wie auch beim post-commit Hook gibt es keine Grenzen in der Umsetzung. Es kann den Code auf Syntax-Fehler prüfen, den Commit verweigern, wenn der Comment nicht den eigenen Standards entspricht oder die Einhaltung der internen Programmierstandards checken.
Inwieweit diese Prüfmechanismen sinnig oder überlüssig sind, hängt ganz vom angewandten System und natürlich jedem Team selbst ab. Ich habe da meine klaren Regeln, was in das Hook gehört, und was nicht.
Die Prüfung auf Syntax-Fehler ist im Produktivsystem unverzichtbar. Was live geht, muss wenigstens vom Syntax her stimmen (von der Logik her natürlich auch). Im Developing ist das allerdings nicht so wichtig, als das eine Prüfung den Commit verweigern sollte. Ebenso ist es im Branch weniger wichtig, dass die Comment-Standards eingehalten werden. Im trunk allerdings schon, denn gerade im hitzigen Gefecht zwischen Bugs und Fixes ist es wichtig, dass irgendjemand auch nach Wochen noch durchblickt, was in welcher Revision eigentlich eingespielt wurde, ohne die History durcharbeiten zu müssen.
Anders sieht es mit den Programmierrichtlinien aus. Diese Prüfung gehört definitiv ausschließlich in den Entwicklungsbereich. In das Produktivsystem kommt so nur standardkonformer Code. Im Falle eines schnellen Bugfix direkt im Live-System, bei dem das Motto "Zeit ist Geld" zählt, sind die Richtlinien ersteinmal Nebensache.
Im Folgenden möchte ich also meine Lösung vorstellen, die die eben geschriebenen Regeln berücksichtigt und umsetzt.
Als erstes müssen wir wissen, wie der Hook arbeitet. Dazu lesen wir uns das Template durch, was im /var/svn/repo/hooks/ Verzeichnis liegt. Dort erfahren wir, dass das Script mit zwei Parametern aufgerufen wird. Zum einen die Pfade, in denen Änderungen vorgenommen wurden, und zum anderen der TXN-Name, der die temporäre Revisionsnummer darstellt.
Mithilfe dieser beiden Parameter können wir nun die genauen Änderungen mittels svnlook-Befehl rausfinden. Nun können wir alle PHP Dateien im trunk, an denen Änderungen vorgenommen wurden, mittels php -l auf Syntax-Fehler prüfen. Jede Datei muss einzeln geprüft werden, und diese Prüfung bauen wir in eine for-Schleife ein.
Das ganze Sript sieht dann so aus:
/var/svn/repo/hooks/pre-commit
| code: | ||
|
Das Script sorgt dafür, dass der enthaltene Fehler direkt an den SVN-Client gemeldet wird. Man bekommt also sofort den Punkt geliefert, wo das Problem aufgetreten ist, ohne im Trüben fischen zu müssen, sofern man im Editor keine Code-Validierung angeschalten hat.
Damit die Datei nun auch ausgeführt wird, muss die die nötigen Rechte erhalten. Der Benutzer, unter dem Subversion ausgeführt wird, muss Ausführrechte erhalten. Achtung: Auch der root-Benutzer muss weitere Rechte eingeräumt bekommen. Deswegen setzen wir, um auf Nummer sicher zu gehen, die vollen Rechte:
chmod 0777 /var/svn/repo/hooks/pre-commit
Und schon ist das pre-commit Hook fertig, was dafür sorgt, dass kein Code mit Syntax-Fehlern ins Live-System gerät. Wenn man sich diese drei Minuten Zeit nimmt, um das Script in den eigenen Repositories zu aktivieren, kann man sich eine Menge Zeit und Ärger sparen. Ich habe im Jahr 2008 tatsächlich mal einen großen Teil einer sehr stark frequentierten Seite lahm gelegt, weil soein Hook nicht vorhanden war, als ich in einer Datei ein Semikolon am Ende einer Zeile vergessen habe.
Nach oben