Entraînement à la création de workflow Github Action

Dépôt d'entraînement à la création de workflow Github Action.

Cette procédure peut être suivie avec l'utilisation d'un projet tel que :

• projet Web Python
• projet React (Client Side Rendering)

Warning

Attention de bien réupérer le code complet du projet disponible sur la branche solution.

---

Les différentes étapes du workflow

La suite de cette procédure vous aiguillera sur la création d'un workflow vous permettant de passer les étapes :

1. Test unitaire
2. Build de production
3. déploiement

Apperçu du workflow :

jobs:
  # 1. Tests unitaires
  test: ...
  # 2. Build de production
  build: ...
  # 3. Déploiement
  deploy: ...

Tip

La suite de cette procédure vous aiguillera la mise en place d'un tel workflow. Il vous est conseillé de suivre toutes les étapes afin de mieux appréhender les concepts et les fonctionnalités des workflows.

---

Etape 1 : création d'un workflow

1. créer projet local avec un dossier .github/workflows
2. créer un fichier ci.yml dans ce dossier, avec le contenu suivant :

name : Github Action learning

# Permissions minimales pour le workflow
permissions:
  contents: read

# Il est possible d'utiliser des variables d'environnement en utilisant ${{ <nom-variable> }}
# https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
run-name : ${{ github.actor }} apprentissage de Github Action
on : [push, workflow_dispatch] # se délenche sur un "push" et peut être démarrer manuellement ("workflow_action")

jobs:
  Github-action-learning:
    runs-on: ubuntu-24.04
    steps:
      - name: Etape 1 - Là où tout commence
        run: echo "It's alive! ALIIIIIVE!"

3. créer un dépôt sur Github et le lier au dépôt local contenant le projet
4. pousser le code sur le dépôt Github

Si tout est bien configurer il devrait être possible d'observer le bon fonctionnement du workflow :

Cycle de vie d'un Workflow :

1. événement
2. recherche du workflow correspondant à l'événement
3. mise en file d'attente
4. attribution d'un "runner"
5. exécution des jobs
6. nettoyage des machines virtuelles

---

Etape 2 : scripting sur le runner

Il est possible d'ajouter à une étape des commandes qui s'exécuteront sur le "runner".

Au sein de ces commandes, des variables de contexte sont fournies par Github Action.

Essayer d'ajouter cette étapes à votre workflow :

- name: Informations diverses
  - run: echo "Le job a été déclenché par ${{ github.event_name }}"

Tip

Sous VS Code, il est possible d'utiliser des extensions telles que GitHub Actions for VS Code pour bénéficier de la coloration syntaxique des variables.

Une fois le workflow poussé l'action se déclenche automatiquement. Il est également possible de déclenche l'action manuellement :

Il est possible de chaîner les commandes pour les exécuter en 1 seul "run" en utilisant |:

- name: Informations diverses
  run: | # Le | permet de chaîner les commandes
    echo "Le job a été déclenché par ${{ github.event_name }}"
    echo "Ce job tourne sur ${{ runner.os }}"
    echo "La branche est ${{ github.ref }} sur le dépôt ${{ github.repository }}"

Etape 3 : récupération du code sur le runner

Parmi les actions disponibles dans le Marketplace il est possible d'utiliser Checkout afin de récupérer un dépôt sur le runner.

Le "checkout" peut s'effectuer avec le code de workflow suivant :

- name: Récupération du code
  uses : actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd

Recommandation de sécurité : utiliser le SHA du commit stable de l'action Github pour cibler l'opération de checkout.

Etape 4 : mise en place de l'environnement dans le runnner

La suite de cette procédure permet de développer le workflow pour automatiser les tests unitaires d'une application web.

Voici les projets que vous pourrez utiliser (à choisir en fonction du langage de votre choix) :

• application en Python;
• application en PHP ;
• application en Java ;
• application en Javascript (uniquement CSR).

Tip

Il vous sera possible d'implémenter le workflow sur un "fork" du dépôt de votre choix ou sur un de vos dépôts.

Récupération du code

Il est possible d'utilisation l'action "checkout", voici un extrait de configuration YML exploitable :

steps:
  - name: Checkout code
    uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd

Note

"de0fac2e4500dabe0009e67214ff5f5447ce83dd" est utilisé pour préciser la version de l'action à utiliser. Ceci est le hash du commit de la v6 de l'action en question.

Installation de l'environnement de développement

Le runner sur lequel le code est récupéré ne bénéficie pas, par défaut, d'environnement de développement.

Des actions spécifiques peuvent le mettre en place, ceci pour plusieurs technologies :

• Python
• PHP
• Java
• Javascript

Par exemple, pour JS :

      - name: Setup Node.js
        uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

Par exemple, pour Python :

      - name: Configuration de Python # https://github.com/marketplace/actions/setup-python
        uses: actions/setup-python@e797f83bcb11b83ae66e0230d6156d7c80228e7c
        # Paramétrage spécifiques :
        # - numéro de version Python
        # - activation du cache pour "pip"
        with:
          python-version: ${{ env.PYTHON_VERSION }}
          cache: 'pip'
          cache-dependency-path: |
            requirements.txt

Tip

La variable d'environnement env.PYTHON_VERSION doit être définie au préalable (avant la balise jobs). Se référer à l'article disponible ici pour plus d'informations.

Installation des dépendances du projet

Une fois l'environnement de développement installé, il est possible de déclencher l'installation des dépendances en utilisant les outils propres à la technologie utilisée.

Pour un projet en JS :

      - name: Installation des dépendances
        run: npm install --frozen-lockfile

Pour un projet Python :

      - name: Installation des dépendances
        # Màj de pip & installation des dépendances listées dans "requirements.txt"
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

Etape 6 : lancement des tests unitaires

Un des intérêts de Github Action est de pouvoir automatiser le lancement des tests unitaires afin de :

• cibler les éventuelles régressions
• interrompre le workflow et empêcher le déploiement
• bloquer une "pull request"

Exemple utilisable dans le cas d'un projet JS avec Vitest :

      - name: Linting (ESLint)
        run: npm run lint

      - name: Tests unitaires
        run: npm run test

Voici un exemple d'étape utilisable dans le cas d'un projet Python :

      - name: Lancement des tests unitaires
        run: |
          echo "Lancement des tests unitaires"
          if ! python -m unittest tests/test_taxi_fare_calculator.py -v; then
            echo "::error:: Les tests unitaires ont échoué. Interruption du pipeline."
            exit 1
          fi

::error:: est une "commande de workflow". Les commandes de Workflow permettent de faire un pont entre le workflow et le runner, par exemple :

• elle permettent de définir des variables d'environnement
• de générer des valeurs utilisées par d'autres actions
• d'ajouter des messages de débogage

::error:: permet de générer une annotation en erreur pour le runner (qui sera visible dans l'apperçu Github Action).

Etape 7 : ajout d'un "job" de build

Suite au "job" de test vous pourrez ajouter la phase de build d'application de production :

 # 2. Build de production
  build:
    name: Build de production
    runs-on: ubuntu-latest
    needs: test

Tip

Ceci a la particularité de re-recréer un nouveau runner Ubuntu.

Puis il sera possible d'ajouter les étapes suivante :

• setup de l'environement de développement
• installation des dépendancces
• build de production
• upload des fichiers build

Pour un projet JS, voici un exemple de "step" :

      - name: Upload des artefacts de build
        uses: actions/upload-artifact@v7
        with:
          name: dist
          path: dist/
          retention-days: 7

Tip

Cette action permet d'uploader le projet compilé sur un runner. Ceci agit comme un espace de stockage temporaire interne à Github. Les "artifacts" stockés peuvent être partagés par plusieurs jobs.

Etape 8 : ajout d'un "job" de déploiement

Tip

La suite de cette procédure ne s'applique uniquement qu'au déploiement en Github Page d'un application web static (pas de backend).

Il est possible de déclarer le job de déploiement de la façon suivante (à la suite du workflow) :

  # 3. Déploiement
  deploy:
    name: Déploiement (GitHub Pages)
    runs-on: ubuntu-latest
    needs: build
    # Ne se déclenche que sur la branche solution
    if: github.ref == 'refs/heads/solution' && github.event_name == 'push'

    permissions:
      contents: read
      pages: write
      id-token: write

    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

Etape 9 : ajout des "steps" de déploiement

Avant de pouvoir effectuer le déploiement sur Github Page via le workflow il faut l'activer sur la page de projet Github :

Les étapes suivantes seront alors utilisables :

steps:
      - name: Téléchargement des artefacts de build
        uses: actions/download-artifact@v8
        with:
          name: dist
          path: dist/

      - name: Setup GitHub Pages
        uses: actions/configure-pages@v6

      - name: Upload vers GitHub Pages
        uses: actions/upload-pages-artifact@v5
        with:
          path: dist/

      - name: Déploiement sur GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v5