Automatiser son workflow avec GitHub Actions

Sommaire

• Introduction
• Qu’est-ce que GitHub Actions ?
  • Les concepts de base
  • Pourquoi automatiser ?
• Votre première GitHub Action
  • Structure d’un workflow
  • Exemple simple : Tests automatiques
• Cas pratiques d’automatisation
  • Tests automatiques sur multiple versions
  • Build et déploiement automatique
  • Notifications et intégrations
• Actions avancées
  • Variables d’environnement et secrets
  • Conditions et matrices
  • Actions personnalisées
• Bonnes pratiques
• FAQ

Introduction

Combien de fois avez-vous oublié de lancer les tests avant de pusher ? Ou passé des heures à déployer manuellement votre application ? GitHub Actions peut transformer votre façon de travailler en automatisant ces tâches répétitives.

Dans cet article, nous allons découvrir comment créer vos premières automations avec GitHub Actions, avec des exemples concrets que vous pourrez adapter à vos projets.

Qu’est-ce que GitHub Actions ?

Les concepts de base

GitHub Actions est la plateforme d’automatisation intégrée à GitHub. Elle permet d’exécuter du code automatiquement en réaction à des événements :

• Push de code à Tests automatiques
• Pull Request à Vérification de qualité de code
• Nouveau tag à Déploiement automatique
• Programmation à Tâches récurrentes

Vocabulaire essentiel :

• Workflow : Le fichier qui définit l’automatisation
• Job : Une série d’étapes qui s’exécutent sur une machine
• Step : Une action individuelle (commande ou action prédéfinie)
• Runner : La machine virtuelle qui exécute le job

Pourquoi automatiser ?

Gain de temps :

• Plus d’oubli de tests avant commit
• Déploiement en un clic
• Pas de répétition de tâches manuelles

Réduction d’erreurs :

• Process standardisé et reproductible
• Validation automatique avant merge
• Rollback facilité en cas de problème

Amélioration de la qualité :

• Tests systématiques sur tous les environnements
• Vérifications de sécurité automatiques
• Standards de code respectés

Votre première GitHub Action

Structure d’un workflow

Les workflows se placent dans .github/workflows/ à la racine de votre projet.

Créons notre premier workflow :

.github/workflows/premier-workflow.yml :

name: Mon Premier Workflow

# Quand déclencher le workflow
on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

# Les tâches à exécuter
jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - name: Récupérer le code
      uses: actions/checkout@v4
      
    - name: Dire bonjour
      run: echo "Hello GitHub Actions!"
      
    - name: Afficher la date
      run: date

Exemple simple : Tests automatiques

Prenons un exemple concret avec une application Node.js :

.github/workflows/tests.yml :

name: Tests Automatiques

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

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - name: Récupérer le code source
      uses: actions/checkout@v4
      
    - name: Installer Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'
        cache: 'npm'
        
    - name: Installer les dépendances
      run: npm ci
      
    - name: Lancer les tests
      run: npm test
      
    - name: Vérifier le linting
      run: npm run lint
      
    - name: Construire l'application
      run: npm run build

Explication étape par étape :

1. checkout@v4 : Télécharge votre code dans le runner
2. setup-node@v4 : Installe Node.js version 18 avec cache npm
3. npm ci : Installe les dépendances (plus rapide que npm install)
4. npm test : Lance votre suite de tests
5. npm run lint : Vérifie la qualité du code
6. npm run build : S’assure que l’application se compile

Cas pratiques d’automatisation

Tests automatiques sur multiple versions

Pour garantir la compatibilité, testez sur plusieurs versions :

name: Tests Multi-Versions

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16, 18, 20]
        
    steps:
    - uses: actions/checkout@v4
    - name: Setup Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        
    - run: npm ci
    - run: npm test

Build et déploiement automatique

Automatisons le déploiement sur Vercel :

name: Deploy to Vercel

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout
      uses: actions/checkout@v4
      
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '18'
        
    - name: Install dependencies
      run: npm ci
      
    - name: Build application
      run: npm run build
      
    - name: Deploy to Vercel
      uses: vercel/action@v1
      with:
        vercel-token: ${{ secrets.VERCEL_TOKEN }}
        vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
        vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
        vercel-args: '--prod'

Notifications et intégrations

Envoi de notification Discord en cas d’échec :

name: Tests avec Notifications

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: '18'
        
    - run: npm ci
    - run: npm test
    
    - name: Notify Discord on failure
      if: failure()
      uses: sarisia/actions-status-discord@v1
      with:
        webhook: ${{ secrets.DISCORD_WEBHOOK }}
        status: failure
        description: "Les tests ont échoué sur la branche ${{ github.ref }}"

Actions avancées

Variables d’environnement et secrets

Pour les secrets sensibles (tokens, mots de passe) :

1. Allez dans Settings à Secrets and variables à Actions
2. Ajoutez vos secrets
3. Utilisez-les dans le workflow :

steps:
- name: Deploy with secret token
  env:
    API_TOKEN: ${{ secrets.API_TOKEN }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
  run: |
    echo "Deploying with secure credentials..."
    # Vos commandes de déploiement ici

Variables d’environnement classiques :

env:
  NODE_ENV: production
  CACHE_VERSION: v1
  
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      BUILD_PATH: ./dist
      
    steps:
    - name: Build with custom env
      run: |
        echo "Environment: $NODE_ENV"
        echo "Building to: $BUILD_PATH"

Conditions et matrices

Conditions avancées :

jobs:
  deploy:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    
  test:
    runs-on: ubuntu-latest
    steps:
    - name: Run expensive tests
      if: contains(github.event.head_commit.message, '[full-test]')
      run: npm run test:full
      
    - name: Quick tests only
      if: "!contains(github.event.head_commit.message, '[full-test]')"
      run: npm run test:quick

Matrices complexes :

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest, macos-latest]
    node-version: [16, 18, 20]
    include:
      - os: ubuntu-latest
        node-version: 20
        experimental: true
    exclude:
      - os: windows-latest
        node-version: 16

Actions personnalisées

Créez votre propre action réutilisable :

.github/actions/setup-project/action.yml :

name: 'Setup Project'
description: 'Install dependencies and setup cache'

inputs:
  node-version:
    description: 'Node.js version'
    required: true
    default: '18'

runs:
  using: 'composite'
  steps:
    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}
        cache: 'npm'
        
    - name: Install dependencies
      run: npm ci
      shell: bash
      
    - name: Cache build artifacts
      uses: actions/cache@v3
      with:
        path: |
          ~/.npm
          .next/cache
        key: ${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }}

Utilisation dans un workflow :

steps:
- uses: actions/checkout@v4
- uses: ./.github/actions/setup-project
  with:
    node-version: '20'

Bonnes pratiques

Organisation des workflows

.github/
  workflows/
    ci.yml              # Tests et vérifications
    cd.yml              # Déploiement
    security.yml        # Audits de sécurité
    release.yml         # Création de releases

Optimisation des performances

Cache les dépendances :

- name: Cache dependencies
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

Parallélisation des jobs :

jobs:
  test:
    runs-on: ubuntu-latest
    # Ce job s'exécute en parallèle
    
  lint:
    runs-on: ubuntu-latest  
    # Celui-ci aussi
    
  deploy:
    needs: [test, lint]  # Attend que test ET lint soient terminés
    runs-on: ubuntu-latest

Gestion des erreurs

steps:
- name: Tests with retry
  uses: nick-invision/retry@v2
  with:
    timeout_minutes: 10
    max_attempts: 3
    command: npm test
    
- name: Upload test results
  if: always()  # S'exécute même si les tests échouent
  uses: actions/upload-artifact@v3
  with:
    name: test-results
    path: test-results.xml

FAQ

Combien ça coûte ?

• Repositories publics : Gratuit et illimité
• Repositories privés : 2000 minutes/mois gratuites, puis payant
• Self-hosted runners : Gratuit (mais vous gérez l’infrastructure)

Comment débugger un workflow qui échoue ?

1. Consultez les logs détaillés dans l’onglet Actions
2. Ajoutez des étapes de debug :

- name: Debug info
  run: |
    echo "Working directory: $(pwd)"
    echo "Files present:"
    ls -la
    echo "Environment variables:"
    env | sort

3. Activez le debug mode :

env:
  ACTIONS_STEP_DEBUG: true

Peut-on utiliser des actions d’autres personnes ?

Oui ! Explorez le Marketplace GitHub Actions.

Exemples populaires :

• actions/setup-python@v4 - Setup Python
• docker/build-push-action@v3 - Build et push Docker
• codecov/codecov-action@v3 - Upload coverage reports

Comment sécuriser mes workflows ?

• Définissez les versions des actions : actions/checkout@v4 plutôt que @main
• Utilisez des secrets pour les données sensibles
• Limitez les permissions :

permissions:
  contents: read
  pull-requests: write

• Validez les inputs dans les actions custom

Comment tester localement ?

Utilisez act :

# Installer act
curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

# Lancer localement
act push

Puis-je déclencher un workflow manuellement ?

Oui avec workflow_dispatch :

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Environment to deploy to'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production

GitHub Actions vous fera gagner énormêment de temps une fois que vous aurez pris le pli. Commencez par automatiser vos tests, puis élargissez progressivement vers le déploiement et les tâches de maintenance !