La vie est trop courte pour passer en revue les espaces

DevOps/Cloud natif en direct !  Boston

La vie est trop courte pour passer en revue les espaces

Sophie Mzabic

Diplômé de l’Ecole Centrale Paris

Ingénieur logiciel full stack | GitGuardian | Responsable technique de l’équipe PQL

Introduction

La plupart des développeurs détestent faire des choses qui pourraient être automatisées.

Comme souligné dans ce tweet, nous devons souvent accepter que nous ne pouvons pas le faire. Heureusement, dans le cas de revues de code, beaucoup de choses peuvent en effet être automatisées. Comme mon ancien CTO me l’a dit une fois

La vie est trop courte pour revoir les espaces !

Entre les doigts des développeurs et les yeux des réviseurs, il y a deux étapes principales où ce processus de révision automatisé peut être effectué :

  • en tant que crochets de pré-commit
  • en tant qu’emplois CI

Dans cet article, nous allons nous concentrer sur l’étape de pré-commit. Nous verrons comment installer et configurer les crochets de pré-commit et nous énumérerons les 8 principaux crochets que nous utilisons chez GitGuardian

Comment configurer des crochets de validation

Dans le livre git, les crochets git sont a way to fire off custom scripts when certain important actions occur.

Dans le cas des crochets de pré-commit – comme son nom l’indique – les scripts sont exécutés juste avant la création du commit, ce qui nous permet de le bloquer s’il ne répond pas à nos exigences. Le principal avantage de lancer des scripts à cette étape est qu’ils peuvent détecter des problèmes avant même qu’ils n’entrent dans le système de contrôle de versionnous permettant de les corriger facilement, voire de les corriger automatiquement.

Chez GitGuardian, nous utilisons pre-commit qui est un gestionnaire de packages multilingue pour les hooks de pré-commit écrits en Python. Il est très facile d’installer et de partager les crochets au sein de notre organisation. Vous trouverez de bonnes alternatives écrites dans d’autres langues comme husky en javascript par exemple.

Installer

  1. Ajouter pre-commit dans votre requirements.txt ou dans votre Pipfile (dans la section dev).
  2. Ajouter un fichier de configuration pré-commit .pre-commit-config.yaml avec la liste des crochets que vous voulez. Voici un exemple tiré de la documentation :
repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.3.0
    hooks:
    -   id: check-yaml
    -   id: end-of-file-fixer
    -   id: trailing-whitespace
-   repo: https://github.com/psf/black
    rev: 21.12b0
    hooks:
    -   id: black

Vous pouvez trouver ici une liste des crochets courants.

3. Courez pre-commit install dans votre environnement Python.

Voici une vidéo à installer pre-commit de pip et installez un hook GitGuardian par exemple.

C’est ça! A partir de maintenant, quand tu courras git commit tous les crochets seront lancés.

Les crochets de pré-commit que nous utilisons chez GitGuardian

Commençons par les crochets du formateur. Comme le suggère le titre de cet article, la dernière chose que nous souhaitons lors de la révision du code est de nous fatiguer en nous concentrant sur le formatage. C’est pourquoi nous avons installé les crochets suivants :

flocon8

  - repo: https://github.com/PyCQA/flake8
    rev: 4.0.1
    hooks:
      - id: flake8
        args: [--config, backend/setup.cfg]
        additional_dependencies: [ggflake8==1.2.1]

flake8 analyse les fichiers python modifiés pour s’assurer que les directives PEP8 sont suivies et bloque la validation si ce n’est pas le cas. De plus, nous avons développé notre propre flake8 plugin que nous avons nommé ggflake8 pour appliquer un ensemble de règles personnalisées telles que :

  • toutes les fonctions de 20 lignes ou plus doivent avoir une docstring
  • une fonction avec 3 arguments ou plus doit utiliser des arguments nommés
  • Les docstrings des tests doivent suivre les Gherkin Format « DONNÉ/QUAND/ALORS ».

le noir

  - repo: https://github.com/psf/black
    rev: 22.3.0
    hooks:
      - id: black
        args: [--config, backend/pyproject.toml]

Nous avons choisi d’ajouter ce formateur fortement opiniâtre au-dessus de flake8 pour supprimer toute discussion sur le formatage. Comme le dit leur documentation :

Black est le formateur de code Python sans compromis. En l’utilisant, vous acceptez de céder le contrôle sur les détails du formatage manuel. En retour, le noir vous donne la vitesse, le déterminisme et la liberté de pycodestyle harceler sur le formatage. Vous gagnerez du temps et de l’énergie mentale pour des questions plus importantes.

D’autres bonnes alternatives incluent pylint et autopep8

trier

  - repo: https://github.com/pycqa/isort
    rev: 5.10.1
    hooks:
      - id: isort
        args: [--settings-path, backend/pyproject.toml]

Comme le dit leur documentation : « triez vos importations pour que vous n’ayez pas à le faire ». C’est un utilitaire Python pratique qui se chargera de formater les importations en les triant par ordre alphabétique et en les séparant par sections et par type. Une chose de moins à s’inquiéter!

plus jolie

  - repo: https://github.com/pre-commit/mirrors-prettier
    rev: v2.5.1
    hooks:
      - id: prettier

prettier et eslint sont utilisés pour formater nos fichiers JSON, YAML et Markdown.

Chèque-*

  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.1.0
    hooks:
      - id: check-json
      - id: check-yaml
      - id: check-added-large-files

Le premier ensemble de crochets vérifie la syntaxe des fichiers JSON et YAML tandis que le check-added-large-files assurez-vous que personne ne commet un gros fichier par erreur.

commettre

  - repo: https://github.com/Woile/commitizen
    rev: v2.20.3
    hooks:
      - id: commitizen
        stages: [commit-msg]

commitizen s’assure que nos messages de validation répondent aux exigences de notre entreprise, qui est un format dérivé de semantic-release où nous devons également mettre le numéro du problème GitLab associé. Voici un exemple de message de validation GitGuardian valide :

chore(pre-commit): #2345 add commitizen hook

sort de code

    - repo: https://github.com/codespell-project/codespell
      rev: v2.1.0
      hooks:
        - id: codespell

codespell vérifie les fautes de frappe. Nous avons choisi cet outil car il est basé sur une liste de fautes de frappe courantes, ce qui réduit au minimum le nombre de faux positifs.

Il s’est avéré être un outil très utile : quel soulagement de ne pas avoir à rejeter le MR de votre collègue à cause d’une petite faute de frappe !

ggshield

  - repo: https://github.com/gitguardian/gg-shield
    rev: v1.12.0
    hooks:
      - id: ggshield

À quel point serait-il idiot de ne pas utiliser notre propre logiciel ?

Les hooks de pré-commit sont également un excellent endroit pour exécuter des tests de sécurité. Comme pour tous les tests, plus tôt les problèmes sont détectés, mieux c’est. Cela est particulièrement vrai pour les problèmes de sécurité, qui peuvent avoir des impacts désastreux.

ggshield est l’un des outils que nous développons chez GitGuardian pour aider à sécuriser la base de code. Intégré en tant que crochet, il analysera le contenu du patch git pour s’assurer qu’il ne contient aucun secret comme un jeton API.

Usage

Maintenant que nos hooks de pré-commit sont installés et configurés, ils seront exécutés à chaque fois que nous essaierons de valider :

La vie est trop courte pour passer en revue les espaces
Les crochets s’exécutent après un commit (sauté ici car aucun fichier)

Mais si pour une raison quelconque vous souhaitez ignorer un ou tous les crochets, vous pouvez facilement le faire

  • ajoutez simplement le -n dispute: git commit -m "message" -n
  • pour ignorer un seul crochet, utilisez : SKIP=flake8 git commit -m "message"

conclusion

Les hooks de pré-commit sont indispensables dans tout projet car ils sont si faciles à configurer et offrent une valeur énorme. Pour les avoir utilisés une fois, je dirais – à mon avis très personnel – que ce serait presque aussi fou de ne pas les utiliser que de ne pas utiliser Git ! (en exagérant un peu, mais vous voyez l’idée)

Néanmoins, cet outil n’est pas infaillible car il peut être ignoré facilement ou ne pas être installé du tout. C’est pourquoi il est important de maintenir les tests et les travaux côté serveur CI, en particulier ceux liés à la sécurité. Les hooks de pré-commit et les jobs CI sont complémentaires. Il montre également que pour les tests de sécurité, une solution complémentaire qui scannerait le VCS côté serveur est toujours nécessaire.

*** Il s’agit d’un blog syndiqué du réseau des blogueurs de sécurité du blog GitGuardian – Détection automatisée des secrets rédigé par Guardians. Lisez le message original sur : https://blog.gitguardian.com/life-too-short-to-review-spaces/

Leave a Comment

Your email address will not be published.