Workflow CI GitHub Actions : Tests & Linters Automatisés

by fritz-hansen 57 views

Salut les développeurs ! Vous en avez marre de vérifier manuellement que votre code est propre et que les tests passent ? Moi aussi, les gars ! C'est pourquoi aujourd'hui, on va plonger dans le monde merveilleux de GitHub Actions pour mettre en place un workflow CI (Intégration Continue) qui va vous sauver la vie. Imaginez : chaque fois que vous poussez du code ou que vous ouvrez une pull request, un petit robot super efficace se lance, fait tous les tests et vérifie la qualité de votre code. Pas mal, non ? On va créer ensemble un fichier de workflow qui va se loger dans .github/workflows/ et qui va automatiser tout ça. Fini les erreurs oubliées et les problèmes de style qui vous font perdre du temps ! Préparez votre café, on commence cette aventure pour rendre votre développement plus fluide et plus professionnel. L'objectif ici est simple : garantir la qualité du code à chaque étape du développement, directement depuis votre dépôt GitHub.

Mise en place du workflow CI avec GitHub Actions

Pour commencer, il faut comprendre ce qu'est un workflow CI et pourquoi c'est super important, surtout dans un projet comme le vôtre sur Keypleunveil repo-92s74wzj. L'intégration continue, c'est cette pratique qui consiste à fusionner régulièrement le travail de tous les développeurs dans une branche partagée, après quoi des builds et des tests automatisés sont exécutés. L'idée, c'est de détecter les problèmes le plus tôt possible. GitHub Actions, c'est la solution intégrée de GitHub pour automatiser ces tâches. Pensez-y comme à un assistant personnel pour votre projet. On va donc créer un fichier YAML (le langage préféré des machines pour les configurations) dans un dossier spécifique : .github/workflows/. Ce fichier va décrire les étapes que GitHub Actions doit suivre. On va le nommer quelque chose de clair, comme ci.yml. Ce fichier va dire : "Quand quelque chose d'important se passe sur mon dépôt (comme un push ou une pull_request), lance cette série de commandes". Ces commandes vont inclure l'installation des dépendances, l'exécution de vos tests (qu'ils soient unitaires, d'intégration, etc.) et le lancement de vos linters pour vérifier le style et la qualité du code. C'est une étape cruciale pour maintenir une base de code saine et faciliter la collaboration entre les membres de l'équipe. En automatisant ces vérifications, vous vous assurez que chaque contribution est validée avant d'être intégrée, ce qui réduit considérablement le risque d'introduire des bugs et facilite le processus de revue de code. Ce workflow va devenir votre première ligne de défense contre les problèmes de qualité.

Configuration du fichier ci.yml pour les tests et linters

Maintenant, passons à la concrète, les potos ! On va créer le fichier ci.yml qui va être le cœur de notre workflow CI. Ce fichier sera placé dans le répertoire .github/workflows/ à la racine de votre projet. Si ce répertoire n'existe pas, créez-le. Une fois le fichier ci.yml créé, voici à quoi il pourrait ressembler :

name: CI Workflow

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.10
      uses: actions/setup-python@v3
      with:
        python-version: "3.10"
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install flake8 pytest
    - name: Lint with flake8
      run: |
        # stop the build if there are Python syntax errors or undefined names
        flake8 . --count --select E9,F63,F7,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
    - name: Test with pytest
      run: pytest

Décortiquons un peu ce code. D'abord, name: CI Workflow donne un nom à notre workflow. Ensuite, on: spécifie quand ce workflow doit se déclencher : ici, lors d'un push sur la branche main ou lors de l'ouverture d'une pull_request ciblant la branche main. C'est super important pour que les tests et le linting s'exécutent sur toutes les modifications importantes. Le bloc jobs: définit les tâches à accomplir. On a un job nommé build qui s'exécutera sur un runner ubuntu-latest, c'est-à-dire une machine virtuelle Linux fournie par GitHub. Les steps: définissent la séquence d'actions.

  • actions/checkout@v3 : cette action permet de récupérer le code de votre dépôt sur le runner. Sans ça, GitHub Actions ne saurait pas sur quel code travailler.
  • actions/setup-python@v3 : ici, on configure l'environnement Python. J'ai choisi la version 3.10, mais vous pouvez l'adapter à vos besoins. Il est essentiel que l'environnement du runner corresponde à celui de votre projet.
  • Install dependencies : cette étape installe les dépendances nécessaires. On met à jour pip (le gestionnaire de paquets Python) puis on installe flake8 (pour le linting) et pytest (pour les tests). Adaptez cette commande si vous utilisez un autre gestionnaire de paquets comme poetry ou pipenv.
  • Lint with flake8 : c'est là que la magie opère pour la qualité du code. flake8 va analyser votre code Python pour détecter les erreurs de syntaxe, les problèmes de style (conformité PEP 8) et d'autres imperfections. Les options utilisées ici (--count, --select E9,F63,F7,F82, --show-source, --statistics) permettent de personnaliser la sortie et les types d'erreurs détectées. La deuxième commande avec --exit-zero est une astuce pour que flake8 ne bloque pas le workflow même s'il trouve des erreurs, ce qui peut être utile pour une première analyse. N'hésitez pas à ajuster ces paramètres pour qu'ils correspondent aux standards de votre équipe.
  • Test with pytest : cette dernière étape exécute vos tests unitaires grâce à pytest. Assurez-vous que vos tests sont bien organisés dans votre projet pour que pytest puisse les trouver et les exécuter correctement. Si vous utilisez un autre framework de test, remplacez pytest par la commande appropriée.

Avec cette configuration, chaque push ou pull_request sur la branche main déclenchera automatiquement ces vérifications. C'est un gain de temps énorme et une garantie de qualité indéniable pour votre projet Keypleunveil repo-92s74wzj.

Optimisation et personnalisation du workflow CI

Les gars, ce qu'on vient de mettre en place est une excellente base, mais on peut aller encore plus loin pour optimiser notre workflow CI. La première chose à considérer, c'est la vitesse. Si notre workflow prend trop de temps à s'exécuter, il peut devenir un frein plutôt qu'une aide. On peut optimiser en installant les dépendances de manière plus efficace, par exemple en utilisant le cache de GitHub Actions. Ça veut dire que si les dépendances n'ont pas changé depuis la dernière exécution, elles seront chargées depuis un cache au lieu d'être réinstallées à chaque fois, ce qui peut réduire considérablement le temps d'exécution. Pensez aussi à exécuter les tests en parallèle si vous avez une suite de tests très longue. Ça demande une configuration un peu plus avancée, mais ça peut diviser le temps d'exécution par deux, voire plus.

Ensuite, parlons de la personnalisation. Notre exemple utilise flake8 pour le linting et pytest pour les tests, mais votre projet utilise peut-être d'autres outils. Par exemple, si vous utilisez black pour le formatage automatique du code, vous pourriez ajouter une étape pour l'exécuter également. Si votre projet a des dépendances spécifiques (comme des bibliothèques de calcul scientifique, des frameworks web, etc.), assurez-vous qu'elles sont bien installées dans la section Install dependencies. Vous pourriez aussi vouloir tester votre code sur différentes versions de Python. Dans ce cas, vous pouvez modifier la section Set up Python pour utiliser une matrice de versions. Par exemple :

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.8", "3.9", "3.10", "3.11"]
    steps:
    - uses: actions/checkout@v3
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: "${{ matrix.python-version }}"
    # ... le reste des étapes pour les dépendances, linting, tests ...

Ça signifie que le job build sera exécuté quatre fois, une fois pour chaque version de Python spécifiée. C'est super pratique pour s'assurer que votre code fonctionne partout. De plus, vous pouvez décider de ce qui bloque une pull_request. Par exemple, si le linting échoue, vous voudrez peut-être que la pull_request soit marquée comme non fusionnable jusqu'à ce que le problème soit résolu. Actuellement, nos commandes flake8 et pytest arrêteront le workflow en cas d'erreur. Si vous voulez des rapports plus détaillés, surtout pour les tests, pytest peut être configuré pour générer des rapports dans des formats lisibles par GitHub Actions, comme le format JUnit XML. Cela permettrait d'afficher les résultats des tests directement dans l'interface de GitHub, ce qui facilite grandement l'analyse des échecs. Il suffit d'ajouter l'option --junitxml=report.xml à votre commande pytest. N'oubliez pas que la clé d'un bon workflow CI est son adaptabilité. Ce fichier YAML est votre toile, et vous pouvez y ajouter autant d'étapes que nécessaire pour couvrir tous les aspects de la qualité de votre projet Keypleunveil repo-92s74wzj, comme la vérification de la sécurité, des types statiques avec mypy, ou même le déploiement.

Intégration et bonnes pratiques pour un workflow CI réussi

L'intégration de ce workflow CI dans votre processus de développement est la dernière étape, mais elle est aussi cruciale. Une fois votre fichier ci.yml créé et commité, GitHub Actions s'occupe du reste. La première fois que vous déclencherez le workflow (par un push ou une pull_request), vous pourrez voir son exécution en direct dans l'onglet