Partager des crochets de pré-validation SVN communs / utiles

Nous avons un hook post-commit qui publie le message sur un compte Twitter. Utilise twitsvn (avertissement: je suis un committer sur ce projet).

Idiot? Peut-être que… mais cela s’est avéré être un bon moyen pour nous de communiquer les activités de notre référentiel à certains de nos membres qui ont des problèmes de contrôle de version. Une fois que SVN a commencé à leur parler via leur client Twitter, cela ne ressemblait pas tellement à une boîte noire.

Qu’un utilisateur a réellement saisi un commentaire sur le message de validation et qu’il contienne un numéro de problème particulier à suivre.

Vérification des chemins absolus dans divers fichiers texte (VRML, XML, etc.). La plupart du code archivé ne devrait jamais avoir de chemin absolu, mais certains utilisateurs et outils insistent pour produire des éléments codés en dur.

Je fais un compte de mots sur les messages soumis. Ils doivent avoir 5 mots ou plus. Cela a conduit à des insultes comiques contre moi …

• Recherchez les tabs et refusez l’enregistrement.
• Vérifiez les fins de ligne incohérentes et rejetez l’archivage.
• Vérifiez la présence de “CR: [nom d’utilisateur]” et refusez l’enregistrement s’il n’y a pas de révision du code.

Vous voudrez peut-être jeter un coup d’œil à: http://svn.apache.org/repos/asf/subversion/twigs/1.6.x/www/tools_consortingb.html#hook_scripts (cette page est peut-être obsolète, de toute évidence, elle n’est plus maintenue). pour Subversion 1.7)

Ou directement à: https://svn.apache.org/repos/asf/subversion/trunk/consortingb/

J’aime utiliser les crochets svn pour:

• appliquer les points plus ssortingcts du style de code
• vérifier les erreurs de syntaxe évidentes
• assurez-vous que les mots-clés Trac spéciaux tels que “Corrections” ou “Adresses” précèdent en fait le numéro d’émission approprié

Je vérifie le type de fichier et vérifie que certains types interdits ne sont pas commis par erreur (par exemple, .obj, .pdb). Eh bien, pas depuis la première fois que quelqu’un a enregistré 2 Go de fichiers temporaires générés par le compilateur 🙁

Pour les fenêtres:

 @echo off svnlook log -t "%2" "%1" | c:\tools\grep -c "[a-zA-z0-9]" > nul if %ERRORLEVEL% NEQ 1 goto DISALLOWED echo Please enter a check-in comment 1>&2 exit 1 :DISALLOWED svnlook changed -t %2 %1 > c:\temp\pre-commit.txt findstr /G:"%1\hooks\ignore-matches.txt" c:\temp\pre-commit.txt > c:\temp\precommit-bad.txt if %ERRORLEVEL% NEQ 0 exit /b 0 echo disallowed file extension >> c:\temp\precommit-bad.txt type c:\temp\precommit-bad.txt 1>&2 exit 1 

J’utilise un hook post-commit pour réécrire la propriété author en un nom convivial de notre arborescence ldap. (l’authentification est avec l’ID d’employé)

Un bon point d’ancrage de nos archives est de vérifier tous les projets de studio visuel de .VCPROJ (ou .CSPROJ) pour s’assurer que les répertoires de sortie n’ont pas été remplacés par des éléments locaux (couramment utilisés pour le débogage).

Ces problèmes se comstackront correctement mais interrompront quand même la construction à cause des exécutables manquants.

Dans la société sur laquelle je travaille actuellement, cela est vérifié:

• Si les fichiers binarys ont l’atsortingbut de locking des besoins;
• Si les fichiers Java ont la notice de copyright standard et si elle inclut l’année en cours;
• Si le code est correctement formaté (nous utilisons Jalopy pour le formatage du code) – cela peut sembler idiot, mais cela facilite les comparaisons de texte entre les différentes versions.
• Si le code a un message de validation;
• Si la structure de répertoires est conforme à ce qui est défini (tous les projets doivent être placés dans un dossier SVN défini, chaque projet doit avoir un répertoire de balises, de twigs et de lignes de réseau);

Je suppose que c’est ça.

J’aime l’idée de vérifier si le commit est associé à un ticket; En fait, cela a beaucoup de sens pour moi.

Certains préfèrent utiliser un outil semblable à des peluches pour une langue donnée afin de trouver des problèmes courants dans le code et / ou appliquer un style de codage. Cependant, dans une équipe restreinte et qualifiée, je préfère autoriser chaque engagement à passer et à résoudre les problèmes éventuels lors de l’continuous integration et / ou de la révision du code. Grâce à cela, les commits sont plus rapides, ce qui encourage des commits plus fréquents, ce qui facilite l’intégration.

J’utilise le hook pre-commit check-mime-type.pl pour vérifier que les options MIME Type et End of line sont définies sur les fichiers validés . J’utilise subversion pour publier des fichiers à afficher sur un site Web utilisant DAV, et tous les fichiers sans le type MIME sont servis en tant que fichiers texte (par exemple, le source HTML est affiché dans un navigateur au lieu du balisage rendu).

Insérez une note dans le bugtracker de Mantis avec les détails de la liste de modifications en fonction du message de validation ayant “issue #” ou similaire via RegEx.

Qu’il ait un message de validation, et que c’est! = Que “correction de bogue”. Merde, j’ai détesté ces messages inutiles!

Nous utilisons un hook de pré-validation et post-commit pour mettre à jour automatiquement bugzilla avec l’entrée associée à svn commit.

Nous utilisons un second hook (pre-commit) pour nous assurer que les propriétés svn: eol-style et svn: keywords sont définies sur un fichier avant qu’il ne soit ajouté au répertoire.

Nous avons un troisième hook (post-commit) pour lancer une génération et envoyer les résultats par courrier si la génération est interrompue, et pour informer tout le monde lorsque la construction a été corrigée à nouveau.

Nous avons un quasortingème hook (post-commit) pour lancer la réplication de svn, pour nous assurer que la réplication hors site est aussi à jour que possible.

Malheureusement, je ne peux pas publier la source sur ceux-ci, mais, à l’exception de l’intégration de Bugzilla, ils sont assez faciles à implémenter et Hudson est probablement un meilleur choix pour une continuous integration.

Pour l’intégration de bugzilla, je suggérerais de regarder scmbug .

J’utilise le script hook suivant pour m’assurer que les fins de ligne du code source et les permissions des scripts shell sont correctes (c’est frustrant lorsque quelqu’un vérifie Windows lorsque tout semble correct et rompt la version unix).

 #!/bin/bash REPOS="$1" TXN="$2" # Exit on all errors. set -e SVNLOOK=svnlook echo "`$SVNLOOK changed -t "$TXN" "$REPOS"`" | while read REPOS_PATH do if [[ $REPOS_PATH =~ A[[:blank:]]{3}(.*)\.(sh|c|h|cpp) ]] then if [ ${#BASH_REMATCH[*]} -ge 2 ] then FILENAME=${BASH_REMATCH[1]}.${BASH_REMATCH[2]}; # Make sure shell scripts are executable if [[ sh == ${BASH_REMATCH[2]} ]] then EX_VALUE="true" if [ -z "`$SVNLOOK propget -t \"$TXN\" \"$REPOS\" svn:executable \"$FILENAME\" 2> /dev/null`" ] then ERROR=1; echo "svn ps svn:executable $EX_VALUE \"$FILENAME\"" >&2 fi EOL_STYLE="LF" else EOL_STYLE="native" fi # Make sure every file has the right svn:eol-style property set if [ $EOL_STYLE != "`$SVNLOOK propget -t \"$TXN\" \"$REPOS\" svn:eol-style \"$FILENAME\" 2> /dev/null`" ] then ERROR=1; echo "svn ps svn:eol-style $EOL_STYLE \"$FILENAME\"" >&2 fi fi fi test -z $ERROR || (echo "Please execute above commands to correct svn property settings." >& 2; exit 1) done 

Que diriez-vous d’un hook pour comstackr le projet? Ex: Run make all. Cela garantit que personne ne vérifie le code qui ne comstack pas! 🙂

Résoudre le manque de fichiers externes dans SVN 1.5 en utilisant PostUpdate et PreCommit

J’apprécierais un hook qui vérifie la note de [Reviewer: xyz] dans le message de validation et rejette le commit.

Je pense à en écrire un pour vérifier les doctype sur les fichiers aspx / html, juste pour m’assurer que tout le monde utilise le bon.

En outre, vous pouvez avoir un hook de validation pré ou post (push) pour envoyer une notification à votre serveur CI comme décrit sur le Blog Hudson.

Je vérifie pour la collision de cas (fenêtres stupides) et exige aussi-mergeinfo.pl pour s’assurer que le client est au moins 1.5 – de cette façon svn: mergeinfo sera toujours défini