Tutoriel GitHub Actions - MLOps Lab

Ce tutoriel a été créé dans le cadre du programme de formation Académie des Mathématiques Appliquées (AMA) pour apprendre à utiliser GitHub Actions dans un contexte MLOps.

Prérequis : Maîtriser Git et Github

Qu'est-ce que GitHub Actions ?

GitHub Actions est une plateforme d'intégration continue et de déploiement continu (CI/CD) intégrée directement à GitHub. Elle permet d'automatiser vos workflows de développement logiciel directement depuis votre dépôt GitHub.

Concepts clés

Workflow : Un processus automatisé configurable qui exécute un ou plusieurs jobs
Event : Une activité spécifique qui déclenche l'exécution d'un workflow (push, pull request, etc.)
Job : Un ensemble d'étapes (steps) qui s'exécutent sur le même runner
Step : Une tâche individuelle qui exécute des commandes ou des actions
Action : Une application réutilisable qui effectue une tâche complexe mais fréquente
Runner : Un serveur qui exécute vos workflows (hébergé par GitHub ou auto-hébergé)

Avantages de GitHub Actions

Intégration native : Directement intégré à GitHub, pas besoin de service externe
Gratuit pour les projets publics : Minutes d'exécution illimitées pour les dépôts publics
Écosystème riche : Accès à des milliers d'actions réutilisables via la GitHub Marketplace
Multi-plateforme : Support de Linux, Windows et macOS
Flexible : Supporte tous les langages et frameworks

Ressources utiles

Documentation officielle GitHub Actions
GitHub Actions Marketplace
Awesome Actions - Liste d'actions communautaires

Guide YAML pour GitHub Actions

Qu'est-ce que YAML ?

YAML (YAML Ain't Markup Language) est un format de sérialisation de données lisible par l'humain. GitHub Actions utilise YAML pour définir les workflows.

Règles de Base

1. Indentation

TOUJOURS utiliser des espaces (jamais de tabulations)
2 espaces par niveau d'indentation
L'indentation définit la hiérarchie

parent:
  enfant:
    petit_enfant: valeur

2. Structures de Données

Scalaires (valeurs simples)

nom: "Alice"
age: 25
actif: true
score: 3.14

Listes (arrays)

# Style 1: avec tirets
fruits:
  - pomme
  - banane
  - orange

# Style 2: inline
couleurs: [rouge, vert, bleu]

Dictionnaires (objets)

personne:
  nom: Alice
  age: 25
  ville: Paris

3. Commentaires

# Ceci est un commentaire
name: Mon Workflow  # Commentaire en fin de ligne

4. Chaînes de Caractères

# Sans guillemets (simple)
message: Bonjour tout le monde

# Avec guillemets doubles (permet l'échappement)
message: "Ligne 1\nLigne 2"

# Avec guillemets simples (littéral)
message: 'Il a dit: "Bonjour"'

# Multi-lignes avec |
script: |
  echo "Ligne 1"
  echo "Ligne 2"
  echo "Ligne 3"

# Multi-lignes avec > (remplace les retours par des espaces)
description: >
  Ceci est une très longue description
  qui sera sur une seule ligne.

5. Valeurs Spéciales

valeur_nulle: null
valeur_vide: ~
booleen_vrai: true
booleen_faux: false

Structure d'un Workflow GitHub Actions

# Nom du workflow (optionnel mais recommandé)
name: Mon Premier Workflow

# Déclencheur(s)
on: push

# Jobs à exécuter
jobs:
  nom-du-job:
    runs-on: ubuntu-latest
    steps:
      - name: Première étape
        run: echo "Hello"

Pièges Courants à Éviter

Erreur : Tabulations

jobs:
    build:  # ❌ Utilise des tabulations

Correct : Espaces

jobs:
  build:  # ✅ Utilise des espaces

Erreur : Indentation incorrecte

jobs:
  build:
  runs-on: ubuntu-latest  # ❌ Mauvaise indentation

Correct

jobs:
  build:
    runs-on: ubuntu-latest  # ✅ Bonne indentation

Erreur : Caractères spéciaux non échappés

message: Il m'a dit: "Bonjour"  # ❌ Guillemets non échappés

Correct

message: "Il m'a dit: \"Bonjour\""  # ✅ Guillemets échappés
# ou
message: 'Il m''a dit: "Bonjour"'

Validation YAML

En ligne de commande (avec Python)

python -c "import yaml; yaml.safe_load(open('workflow.yml'))"

Éditeurs recommandés

VS Code avec extension "YAML" par Red Hat
PyCharm (support natif)
Validation en ligne : yamllint.com

Syntaxe GitHub Actions Spécifique

Variables d'environnement

env:
  MA_VARIABLE: valeur
  PYTHON_VERSION: 3.9

Expressions

# Utilise la syntaxe ${{ }}
if: ${{ github.ref == 'refs/heads/main' }}
run: echo "Branch: ${{ github.ref }}"

Secrets

env:
  API_KEY: ${{ secrets.MA_CLE_API }}

Résumé des Bonnes Pratiques

À FAIRE

Utiliser 2 espaces pour l'indentation
Valider votre YAML avant de committer
Ajouter des commentaires pour expliquer les sections complexes
Utiliser des noms descriptifs pour les jobs et steps

À ÉVITER

Les tabulations
L'indentation incohérente
Les fichiers sans validation préalable
Les noms génériques comme "job1", "step1"

Création de votre premier workflow

Structure des dossiers

GitHub Actions recherche automatiquement les workflows dans un emplacement spécifique de votre dépôt :

votre-repo/
└── .github/
    └── workflows/
        ├── workflow1.yml
        ├── workflow2.yml
        └── ...

Importance de la structure `.github/workflows/`

.github/ : Dossier spécial reconnu par GitHub pour stocker la configuration du dépôt
workflows/ : Sous-dossier où GitHub cherche automatiquement les fichiers de workflow
Les fichiers doivent avoir l'extension .yml ou .yaml
Tous les fichiers YAML dans ce dossier seront automatiquement détectés et exécutés selon leurs déclencheurs

Création du dossier workflows

Via la ligne de commande :

# À la racine de votre dépôt
mkdir -p .github/workflows

Via l'interface GitHub :

Allez dans l'onglet "Actions" de votre dépôt
Cliquez sur "New workflow"
GitHub créera automatiquement la structure nécessaire

Création d'un fichier workflow

Méthode 1 : Via l'interface GitHub

Allez dans "Actions" > "New workflow"
Choisissez "set up a workflow yourself"
Éditez le fichier directement dans le navigateur

Méthode 2 : En local

# Créez un nouveau fichier workflow
touch .github/workflows/mon-premier-workflow.yml

# Éditez avec votre éditeur préféré
code .github/workflows/mon-premier-workflow.yml

Vérification et activation

Une fois le fichier créé et poussé sur GitHub :

Allez dans l'onglet "Actions" de votre dépôt
Votre workflow apparaîtra dans la liste
Il s'exécutera selon les déclencheurs définis (push, pull_request, etc.)

Marketplace GitHub Actions

La GitHub Marketplace offre des milliers d'actions prêtes à l'emploi :

Actions officielles : Maintenues par GitHub (ex: actions/checkout, actions/setup-python)
Actions communautaires : Créées par la communauté open-source
Actions vérifiées : Validées par GitHub pour la sécurité et la qualité

Exemples d'actions populaires :

actions/checkout@v4 : Clone votre dépôt
actions/setup-python@v5 : Configure un environnement Python
docker/build-push-action@v5 : Build et push d'images Docker
aws-actions/configure-aws-credentials@v4 : Configuration AWS

Utilisation d'une action du Marketplace :

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
    with:
      python-version: '3.11'

Gestion des Secrets et Variables

Secrets GitHub

Les secrets sont des variables chiffrées utilisées pour stocker des informations sensibles (clés API, tokens, mots de passe).

Caractéristiques des secrets

Chiffrés : Stockés de manière sécurisée et chiffrés au repos
Masqués dans les logs : Automatiquement masqués dans les sorties des workflows
Lecture seule : Une fois créés, ils ne peuvent pas être lus, seulement mis à jour ou supprimés
Scopes multiples : Repository, Organization ou Environment

Créer un secret au niveau du dépôt

Allez dans Settings de votre dépôt
Dans le menu latéral, cliquez sur Secrets and variables > Actions
Cliquez sur New repository secret
Donnez un nom au secret (ex: API_KEY)
Entrez la valeur
Cliquez sur Add secret

Utiliser un secret dans un workflow

name: Workflow avec Secrets

on: push

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Utiliser un secret
        env:
          API_KEY: ${{ secrets.API_KEY }}
        run: |
          echo "La clé API est masquée dans les logs"
          # La valeur du secret est disponible dans $API_KEY

Important : Les secrets ne sont jamais affichés en clair dans les logs. Si vous faites echo ${{ secrets.API_KEY }}, GitHub remplacera automatiquement la valeur par ***.

Variables GitHub

Les variables sont similaires aux secrets mais pour des données non sensibles.

Différences entre Secrets et Variables

Aspect	Secrets	Variables
Usage	Données sensibles	Configuration non sensible
Visibilité	Masqués dans les logs	Visibles dans les logs
Chiffrement	Chiffrés	Non chiffrés
Lecture	Impossible après création	Possible
Exemple	Tokens, mots de passe	URLs, noms d'environnement

Créer une variable au niveau du dépôt

Allez dans Settings de votre dépôt
Cliquez sur Secrets and variables > Actions
Onglet Variables
Cliquez sur New repository variable
Donnez un nom (ex: DEPLOYMENT_URL)
Entrez la valeur
Cliquez sur Add variable

Utiliser une variable dans un workflow

name: Workflow avec Variables

on: push

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Utiliser une variable
        run: |
          echo "Déploiement vers: ${{ vars.DEPLOYMENT_URL }}"
          echo "Environment: ${{ vars.ENVIRONMENT }}"

Scopes des Secrets et Variables

1. Repository Secrets/Variables

Scope : Un seul dépôt

Utilisation : Spécifiques à un projet

Accès : ${{ secrets.NOM }} ou ${{ vars.NOM }}

2. Organization Secrets/Variables

Scope : Tous les dépôts d'une organisation (ou une sélection)

Utilisation : Valeurs partagées entre plusieurs projets

Configuration :

Allez dans les Settings de l'organisation
Secrets and variables > Actions
Créez un secret/variable d'organisation
Sélectionnez les dépôts qui y ont accès

Priorité : Les secrets de dépôt surchargent ceux de l'organisation

3. Environment Secrets/Variables

Scope : Liés à un environnement spécifique (voir section suivante)

Utilisation : Configurations spécifiques par environnement (dev, staging, production)

Accès : Uniquement dans les jobs qui référencent l'environnement

Bonnes Pratiques pour les Secrets

À FAIRE

Utiliser des secrets pour toutes les données sensibles
Nommer les secrets en MAJUSCULES avec underscores (ex: DB_PASSWORD)
Documenter les secrets nécessaires dans votre README
Utiliser des environnements pour les secrets sensibles (production)
Régénérer régulièrement les tokens et clés

À ÉVITER

Hardcoder des secrets dans le code
Afficher des secrets dans les logs (même partiellement)
Partager des secrets entre environnements dev/prod
Utiliser des variables pour des données sensibles

Exemple de mauvaise pratique :

# ❌ NE JAMAIS FAIRE
steps:
  - name: Mauvaise pratique
    run: echo "Mon token est abc123xyz"  # Hardcodé !

Exemple de bonne pratique :

# ✅ BONNE PRATIQUE
steps:
  - name: Bonne pratique
    env:
      TOKEN: ${{ secrets.GITHUB_TOKEN }}
    run: |
      # Le token est sécurisé et masqué
      curl -H "Authorization: token $TOKEN" https://api.github.com

Environnements GitHub

Les environnements permettent de configurer des règles de déploiement et des secrets spécifiques pour différentes phases du cycle de vie (développement, staging, production).

Qu'est-ce qu'un environnement ?

Un environnement GitHub est une configuration qui regroupe :

Des secrets et variables spécifiques
Des règles de protection (approbations, délais)
Un historique de déploiement
Une URL de déploiement

Créer un environnement

Allez dans Settings de votre dépôt
Cliquez sur Environments dans le menu latéral
Cliquez sur New environment
Donnez un nom (ex: production, staging, development)
Cliquez sur Configure environment

Configuration des environnements

Protection Rules (Règles de protection)

Required reviewers (Réviseurs obligatoires)

Définir qui doit approuver avant le déploiement
Maximum de 6 réviseurs
Utile pour la production

Wait timer (Délai d'attente)

Ajouter un délai avant le déploiement (0-43200 minutes)
Permet des vérifications automatiques ou manuelles

Deployment branches (Branches de déploiement)

Limiter les branches autorisées à déployer
Options :
- All branches : Toutes les branches
- Protected branches : Seulement les branches protégées
- Selected branches : Branches spécifiques (avec patterns)

Environment Secrets et Variables

Chaque environnement peut avoir ses propres secrets et variables :

Dans la configuration de l'environnement
Section Environment secrets ou Environment variables
Cliquez sur Add secret ou Add variable
Ces secrets/variables ne sont accessibles que dans les jobs utilisant cet environnement

Utiliser un environnement dans un workflow

name: Déploiement avec Environnements

on:
  push:
    branches: [main]

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging  # Référence l'environnement staging
    steps:
      - name: Déployer en staging
        env:
          API_KEY: ${{ secrets.API_KEY }}  # Secret de l'environnement staging
          API_URL: ${{ vars.API_URL }}     # Variable de l'environnement staging
        run: |
          echo "Déploiement en staging vers $API_URL"

  deploy-production:
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment:
      name: production
      url: https://app.example.com  # URL accessible depuis l'interface GitHub
    steps:
      - name: Déployer en production
        env:
          API_KEY: ${{ secrets.API_KEY }}  # Secret de l'environnement production
          API_URL: ${{ vars.API_URL }}     # Variable de l'environnement production
        run: |
          echo "Déploiement en production vers $API_URL"

Exemple d'architecture multi-environnements

name: Pipeline Multi-Environnements

on:
  push:
    branches: [develop, main]

jobs:
  # Développement : déploiement automatique
  deploy-dev:
    if: github.ref == 'refs/heads/develop'
    runs-on: ubuntu-latest
    environment: development
    steps:
      - name: Déployer en dev
        run: echo "Déploiement automatique en dev"

  # Staging : déploiement avec délai
  deploy-staging:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Déployer en staging
        run: echo "Déploiement en staging"

  # Production : nécessite approbation manuelle
  deploy-production:
    if: github.ref == 'refs/heads/main'
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    steps:
      - name: Déployer en production
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: echo "Déploiement en production (après approbation)"

Visualisation et historique des déploiements

GitHub fournit une interface visuelle pour suivre les déploiements :

Onglet Code du dépôt
Section Environments (colonne de droite)
Cliquez sur un environnement pour voir :
- Historique des déploiements
- Statut actuel (Active/Inactive)
- URL de déploiement
- Qui a déployé et quand

Recommandations :

Utiliser des secrets différents par environnement (jamais les mêmes clés API)
Nommer les environnements de manière cohérente (development, staging, production)
Toujours protéger l'environnement de production avec des approbations
Documenter les secrets requis pour chaque environnement
Configurer des URLs de déploiement pour faciliter l'accès

Exemple de documentation des secrets par environnement :

Secrets requis par environnement

Development

API_KEY : Clé API de développement
DB_URL : URL de la base de données de dev

Staging

API_KEY : Clé API de staging
DB_URL : URL de la base de données de staging

Production

API_KEY : Clé API de production (sensible !)
DB_URL : URL de la base de données de production (sensible !)
SENTRY_DSN : Pour le monitoring des erreurs

Consulter et gérer vos Workflows

Accéder à l'onglet Actions

Pour visualiser tous les workflows de votre dépôt :

Ouvrez votre dépôt sur GitHub
Cliquez sur l'onglet Actions (entre "Pull requests" et "Projects")
Vous accédez au tableau de bord des workflows

Vue d'ensemble des workflows

Dans l'onglet Actions, vous trouverez :

Panneau de gauche - Liste des workflows

Tous les workflows définis dans .github/workflows/
Chaque workflow est identifié par son nom (défini par name: dans le fichier YAML)
Le nombre d'exécutions récentes est affiché à côté de chaque workflow

Zone centrale - Historique des exécutions

Liste chronologique de toutes les exécutions de workflows
Statut de chaque exécution : ✅ Succès, ❌ Échec, 🟡 En cours, ⚪ Annulé
Filtrage possible par workflow, branche, événement déclencheur, statut

Filtrer par branche

Pour voir les workflows d'une branche spécifique :

Dans l'onglet Actions, utilisez le menu déroulant Branch
Sélectionnez la branche souhaitée (main, develop, feature/xyz, etc.)
L'historique affichera uniquement les exécutions de cette branche

Alternative :

Accédez à l'URL : https://github.com/votre-utilisateur/votre-repo/actions?query=branch:nom-de-branche

Workflows en cours d'exécution

Pour voir les workflows actuellement en cours :

Dans l'onglet Actions, les workflows en cours apparaissent en haut de la liste
Icône 🟡 (jaune) avec animation pour indiquer l'exécution en cours
Cliquez sur le workflow pour voir les détails en temps réel :
- Jobs en cours d'exécution
- Logs en direct de chaque step
- Temps écoulé

Annuler une exécution en cours :

Cliquez sur le workflow en cours
Bouton Cancel workflow en haut à droite

Workflows déjà exécutés

Pour consulter l'historique des exécutions passées :

Dans l'onglet Actions, parcourez la liste chronologique
Filtrez par statut : Success, Failure, Cancelled
Cliquez sur une exécution pour voir :
- Tous les jobs et leurs statuts
- Les logs détaillés de chaque step
- Les artefacts générés (si disponibles)
- Le temps d'exécution total

Réexécuter un workflow :

Ouvrez l'exécution terminée
Bouton Re-run jobs pour relancer le workflow

Déclencher manuellement un workflow

Les workflows avec déclencheur workflow_dispatch peuvent être lancés manuellement.

Important : Les workflows manuels ne sont disponibles que sur la branche principale (main ou master).

Pour déclencher un workflow manuel :

Allez dans l'onglet Actions
Dans le panneau de gauche, sélectionnez le workflow souhaité
Si le workflow a un déclencheur workflow_dispatch, vous verrez un bouton Run workflow
Cliquez sur Run workflow
Sélectionnez la branche (généralement main)
Si le workflow définit des inputs, remplissez les champs requis
Cliquez sur Run workflow (bouton vert)

Exemple de workflow manuel avec inputs :

name: Déploiement Manuel

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Environnement de déploiement'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production
      version:
        description: 'Version à déployer'
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Afficher les paramètres
        run: |
          echo "Environnement: ${{ inputs.environment }}"
          echo "Version: ${{ inputs.version }}"

Note : Si vous ne voyez pas le bouton "Run workflow", vérifiez que :

Vous êtes sur la branche principale (main ou master)
Le workflow contient bien workflow_dispatch dans la section on:
Vous avez les permissions nécessaires sur le dépôt

Notifications et badges

Recevoir des notifications :

GitHub vous notifie automatiquement des échecs de workflows
Configurez vos préférences dans Settings > Notifications

Ajouter un badge de statut dans votre README :

![Workflow Status](https://github.com/votre-utilisateur/votre-repo/actions/workflows/nom-workflow.yml/badge.svg)

Ce badge affiche en temps réel le statut du dernier workflow exécuté.

Workflows du Tutoriel

Ce tutoriel est organisé en une série de workflows progressifs pour apprendre GitHub Actions étape par étape :

Workflows de base

01-hello-world.yml
Premier workflow simple affichant "Hello World" - Introduction aux concepts de base (name, on, jobs, steps)
02-triggers.yml
Exploration des différents déclencheurs : push, pull_request, schedule (cron), workflow_dispatch (manuel)
03-setup-python.yml
Configuration d'un environnement Python avec actions/setup-python et vérification de l'installation
04-dependencies.yml
Installation et gestion des dépendances Python avec pip et requirements.txt

Workflows intermédiaires

05-parallel-jobs.yml
Exécution de plusieurs jobs en parallèle pour optimiser le temps d'exécution
06-sequential-pipeline.yml
Création d'un pipeline avec jobs séquentiels et gestion des dépendances entre jobs (needs)
07-artefacts.yml
Gestion des artefacts : upload et download de fichiers entre jobs avec actions/upload-artifact et actions/download-artifact
08-matrix.yml
Utilisation des matrix strategies pour tester sur plusieurs versions de Python et systèmes d'exploitation

Workflows avancés

09-env-vars.yml
Travail avec les variables d'environnement : définition au niveau workflow, job et step
10-conditions.yml
Exécution conditionnelle avec if, expressions et contextes GitHub
11-secrets.yml
Gestion sécurisée des secrets et informations sensibles avec GitHub Secrets

Pipeline complet

12-pipelines-complet.yml
Pipeline MLOps complet intégrant tous les concepts : lint, tests, build, déploiement avec gestion d'artefacts, conditions et environnements

Prochaine étape : Explorez les workflows dans l'ordre pour une progression pédagogique optimale.

Ressources

Github Skills : https://github.com/skills/hello-github-actions
Tutoriel Github Actions par Github : https://docs.github.com/en/actions/tutorials
Github Actions Video : https://www.youtube.com/watch?v=TLB5MY9BBa4
Extension Github Actions Vscode : https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-github-actions

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
images		images
.gitignore		.gitignore
README.md		README.md
model.py		model.py
requirements.txt		requirements.txt
test_script.py		test_script.py

Latest commit

History

Folders and files

Repository files navigation