5. GitHub — Introduction au CI/CD

Ce chapitre présente les notions dans un ordre progressif. Les commandes illustrent le fonctionnement ; les manipulations guidées sont regroupées dans les TP.

5.1 CI, livraison continue et déploiement continu

Un simple push n’est pas une release. Une release identifie une version livrable ; son artefact et son historique doivent permettre de savoir ce qui a été déployé.

5.2 Le cas des modèles de machine learning

Le support illustre le cycle données brutes → préparation → entraînement → déploiement → nouvelles données. MLOps automatise et trace ces opérations. Une modification des données ou du modèle peut nécessiter de nouveaux contrôles, pas uniquement une compilation du code.

Un pipeline ne garantit pas la pertinence métier du modèle : les validations de données, de performance et la surveillance complètent les tests logiciels.

5.3 Workflow, job, step, action et runner

Les jobs peuvent s’exécuter en parallèle. Chacun dispose de son contexte d’exécution : leurs fichiers ne sont pas automatiquement partagés. Les runners hébergés usuels offrent un environnement neuf pour le job ; un runner autohébergé dépend de votre gestion du serveur.

5.4 Les clés d’un workflow

5.5 Exemple : matrice et étapes

name: Commandes shell
on: [push, workflow_dispatch]
permissions:
  contents: read
jobs:
  diagnostic:
    strategy:
      matrix:
        os: [ubuntu-22.04, ubuntu-24.04]
    runs-on: ${{ matrix.os }}
    steps:
      - name: Message
        run: echo "Hello world"
      - name: Environnement
        run: |
          python3 -V
          pwd

La matrice produit deux exécutions du même job, chacune avec deux étapes. Cet exemple ne lit pas les fichiers du dépôt. Pour tester le projet, il faut d’abord récupérer son contenu avec une action de checkout.

5.6 Dépendances, shells et diagnostic

needs: diagnostic attend la réussite de diagnostic avant de démarrer le job dépendant, sauf condition spécifique. Une étape run choisit un shell : bash, pwsh ou python selon le besoin. Les systèmes Windows et Linux ne partagent pas les mêmes commandes.

Dans Actions, lire l’événement, le job puis la première étape en échec. ACTIONS_STEP_DEBUG=true augmente les traces des étapes ; ACTIONS_RUNNER_DEBUG=true ajoute des diagnostics du runner. Ces réglages peuvent être fournis comme secrets ou variables, sans afficher de données sensibles dans les scripts.

5.7 Construire un workflow Actions lisible

Un workflow est un fichier YAML placé dans .github/workflows/. Il décrit quand démarrer, où exécuter les tâches et quelles étapes lancer.

name: CI main

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.x"
      - run: pip install -r requirements.txt
      - run: pytest