Journal Verification de Syntaxe avant un commit

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
9
oct.
2003
Bonjour,

Y a t-il un moyen avec un système de gestion de version comme CVS de faire une vérification du code AVANT le commit pour s'assurer qu'il respecte bien des règles de nommage et de codage définies ?
Si le fichier n'est pas correct, le commit serait refusé (avec idéalement une identification des lignes qui ne répondent pas aux règles définies).

Merci d'avance pour vos lumières.

  • # Re: Verification de Syntaxe avant un commit

    Posté par  (site web personnel) . Évalué à 3.

    Faut bien que quelqu'un le dise, alors pourquoi pas moi : une liste CVS serait surement plus efficace pour répondre.

    De mémoire, on peut rajouter un (ou plusieurs) exécutable, mais je crois que ça ne fonctionne pas si tu est en mode client/serveur.

    Je pense que le plus simple va etre pour toi de faire une surcouche a 'cvs commit' (ex: CVScommit ;-)).

  • # Re: Verification de Syntaxe avant un commit

    Posté par  (site web personnel) . Évalué à 3.

    Il me semble qu'il existe dans CVS côté serveur une option qui permet de lancer un exécutable à chaque committ, lequel peut justement s'occuper de la validation du code source. Evidement, le fichier sera déja comitté. Mais il est possible de mettre en place assez facilement un système qui recompile le programme, le teste automatiquement, et envoie en cas de bugs un rapport aux différents développeurs.
    On appelle ça du Continous Integration.
    En Java (pour parler de ce que je connais) on fait ça avec Ant, lequel permet les choses suivantes :
    - compiler tout le code
    - exécuter des tests unitaires
    - générer la javadoc avec plusieurs doclets différents (pour obtenir par exemple une version intégrant les infos UML)
    - appliquer un outil de contrôle et d'application de normes de codage (il va donc automatiquement modifier le code pour qu'il corresponde à ces normes)
    - appliquer un outil de gestion et de reporting des dépendances croisées
    - voire même un outil de recherche statique de bugs
    - et pour les "fameuses" webapps, publier le code (déja encapsulé dans un war) sur le serveur ftp (ou scp) correspondant au serveur d'application, afin d'automatiser le redéploiement.

    • [^] # Re: Verification de Syntaxe avant un commit

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Merci pour tous ces renseignements, c'est effectivement pour appliquer a du Java. Pour le continous intégration, on fonctionne à peu près dans le même esprit que ce tu viens de décrire, a quelques détails près:
      - On va certainement passer à Cruise Control pour gérer le processus d'intégration continue. ca semble stable, efficace et ca permet de garder nos scripts ant avec peu de modifs.
      - Je suis plutot du genre Checkstyle que Jalopy. c.a.d., je prefere un outil qui me signale les erreurs mais ne les corrige pas. nous ne souhaitons pas un outil qui touche/modifie du code automatiquement ; On le considère comme potentiellement à risque.

      C'est justement pourquoi je souhaiterais lancer un outil comme checkstyle au moment du commit et qui refuserait de le commiter si des erreurs étaient détectées. A charge au dev de le rendre correct (à l'aide d'un pretty printer bien configuré s'il prefere coder avec ses conventions à lui) avant de commiter.

      En tout cas, merci pour ton aide !

  • # Re: Verification de Syntaxe avant un commit

    Posté par  . Évalué à 4.

    La base administrative (module CVSROOT) de CVS contient un fichier commitinfo qui permet de déclencher des actions lors de commit :

    Extrait du commitinfo :
    # The "commitinfo" file is used to control pre-commit checks.
    # The filter on the right is invoked with the repository and a list
    # of files to check. A non-zero exit of the filter program will
    # cause the commit to be aborted.
    #
    # The first entry on a line is a regular expression which is tested
    # against the directory that the change is being committed to, relative
    # to the $CVSROOT. For the first match that is found, then the remainder
    # of the line is the name of the filter to run.
    #
    # If the repository name does not match any of the regular expressions in this
    # file, the "DEFAULT" line is used, if it is specified.
    #
    # If the name "ALL" appears as a regular expression it is always used
    # in addition to the first matching regex or "DEFAULT".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.