GitHub Actions

La plateforme d'automatisation intégrée à GitHub qui permet de créer des workflows personnalisés pour construire, tester et déployer vos projets directement depuis votre dépôt.

Retour aux compétences Documentation officielle

Pour les non-initiés

Qu'est-ce que GitHub Actions ?

Imaginez que vous dirigiez une boutique de pâtisserie. Chaque jour, vous devez répéter plusieurs étapes manuelles : préparer la pâte, cuire les gâteaux, vérifier leur qualité, les emballer, et les livrer. Ce serait merveilleux d'avoir un assistant qui prendrait en charge automatiquement certaines de ces tâches, n'est-ce pas ?

GitHub Actions est cet assistant pour les développeurs. C'est un outil qui automatise des tâches répétitives dans le processus de développement logiciel, directement intégré à GitHub, la plateforme où les développeurs stockent leur code.

Comment ça fonctionne ?

Workflows automatisés

Définissez une série d'actions à exécuter automatiquement lorsque certains événements se produisent, comme quand quelqu'un ajoute du nouveau code au projet.

Qualité garantie

Vérifiez automatiquement que les nouveaux ajouts au code ne causent pas de problèmes, comme un chef pâtissier qui vérifie que chaque gâteau est parfait avant de le servir.

En résumé, GitHub Actions permet aux équipes de développement de gagner du temps en automatisant les tâches répétitives, d'améliorer la qualité du code, et de faciliter le déploiement des applications. C'est comme avoir un assistant infatigable qui travaille 24/7 pour vous.

Pour les développeurs

Fonctionnement technique

GitHub Actions est une plateforme CI/CD (Intégration Continue/Déploiement Continu) intégrée qui vous permet d'automatiser votre workflow de développement logiciel directement depuis votre dépôt GitHub. Les workflows sont définis dans des fichiers YAML stockés dans le répertoire .github/workflows de votre dépôt.

Concepts fondamentaux

Structure des workflows

Un workflow GitHub Actions est composé de plusieurs éléments clés :

Triggers (Events) : Définissent quand un workflow est exécuté (ex. push, pull request, schedule)
Jobs : Ensembles d'actions qui s'exécutent sur le même runner
Steps : Tâches individuelles qui exécutent des actions ou des commandes shell
Actions : Applications réutilisables qui effectuent des tâches complexes mais fréquentes
Runners : Serveurs qui exécutent les jobs (hébergés par GitHub ou auto-hébergés)

Exemple de workflow basique

Voici un exemple de workflow pour construire et tester une application Node.js :

.github/workflows/ci.yml

name: CI

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '16'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Lint code
      run: npm run lint
    
    - name: Run tests
      run: npm test
    
    - name: Build application
      run: npm run build

Workflow de déploiement

Exemple d'un workflow qui déploie une application sur AWS S3 et invalide le cache CloudFront :

.github/workflows/deploy.yml

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '16'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Build application
      run: npm run build
    
    - name: Deploy to AWS S3
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --acl public-read --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'eu-west-3'
        SOURCE_DIR: 'build'
    
    - name: Invalidate CloudFront cache
      uses: chetan/invalidate-cloudfront-action@v2
      env:
        DISTRIBUTION: ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }}
        PATHS: '/*'
        AWS_REGION: 'eu-west-3'
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Stratégie de matrice

La stratégie de matrice permet d'exécuter un job sur plusieurs configurations :

.github/workflows/cross-platform-test.yml

name: Cross-Platform Testing

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [14.x, 16.x, 18.x]
        exclude:
          - os: windows-latest
            node-version: 14.x
    
    steps:
    - uses: actions/checkout@v3
    
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run tests
      run: npm test
    
    - name: Upload test results
      uses: actions/upload-artifact@v3
      with:
        name: test-results-${{ matrix.os }}-${{ matrix.node-version }}
        path: test-results/

Création d'une action personnalisée

Vous pouvez créer vos propres actions réutilisables :

action.yml

# action.yml
name: 'Website Screenshot'
description: 'Takes a screenshot of a website and uploads it as an artifact'

inputs:
  url:
    description: 'URL of the website to screenshot'
    required: true
  width:
    description: 'Screenshot width in pixels'
    required: false
    default: '1280'
  height:
    description: 'Screenshot height in pixels'
    required: false
    default: '720'

runs:
  using: 'composite'
  steps:
    - name: Install Puppeteer
      shell: bash
      run: npm install puppeteer
      
    - name: Take screenshot
      shell: bash
      run: |
        node -e "(async () => {
          const puppeteer = require('puppeteer');
          const browser = await puppeteer.launch();
          const page = await browser.newPage();
          await page.setViewport({ width: ${{ inputs.width }}, height: ${{ inputs.height }} });
          await page.goto('${{ inputs.url }}', { waitUntil: 'networkidle0' });
          await page.screenshot({ path: 'screenshot.png' });
          await browser.close();
        })()"

Caractéristiques avancées

Secrets : Stockage sécurisé des données sensibles, accessibles via ${{ secrets.NOM_DU_SECRET }}
Variables d'environnement : Définies au niveau du workflow, du job ou de l'étape
Artifacts : Fichiers persistants entre les jobs ou les workflows successifs
Caching : Stockage de dépendances pour accélérer les futures exécutions
Self-hosted runners : Exécuteurs personnalisés pour des environnements spécifiques
Workflows composés : Réutilisation de workflows dans d'autres workflows
Expressions et contextes : Syntaxe puissante pour accéder aux données et aux variables
Conditionnels : Exécution conditionnelle de steps et de jobs

Bonnes pratiques

Minimiser l'utilisation des secrets : N'utilisez des secrets que lorsque c'est nécessaire et limitez leurs permissions
Utiliser des versions précises pour les actions : Préférez actions/checkout@v3 à actions/checkout@main pour la stabilité
Optimiser les workflows : Utilisez le cache pour les dépendances et les artefacts
Nommer clairement les workflows et les jobs : Facilitez la compréhension dans l'interface GitHub
Tester les workflows localement : Utilisez des outils comme act pour tester localement
Limiter le temps d'exécution : Optimisez vos workflows pour économiser des ressources
Organiser les workflows : Séparez les préoccupations dans différents fichiers de workflow
Utiliser la stratégie de matrice : Pour tester sur plusieurs environnements ou configurations

Applications concrètes

Cas d'usage

Intégration continue

Détection précoce des erreurs grâce à l'exécution automatique des tests, linting et autres vérifications de qualité à chaque modification de code, assurant que toute nouvelle contribution respecte les standards du projet.

Déploiement continu

Automatisation complète du processus de déploiement vers différents environnements (développement, staging, production) avec des contrôles de qualité intermédiaires, réduisant les erreurs humaines et accélérant la mise en production.

Construction d'artefacts

Génération automatique de binaires, packages ou documentation à chaque release, avec stockage sur GitHub Packages ou d'autres référentiels, simplifiée par l'intégration native avec l'écosystème GitHub.

Automatisation des tâches périodiques

Exécution automatique de tâches de maintenance comme la mise à jour des dépendances, la génération de rapports ou la sauvegarde de données selon un calendrier prédéfini, sans nécessiter d'intervention manuelle.

GitHub Actions vs Alternatives

Voici comment GitHub Actions se compare aux autres solutions CI/CD :

Solution	Points forts	Idéal pour
GitHub Actions	Intégration native avec GitHub, large marketplace d'actions prédéfinies	Projets déjà hébergés sur GitHub
Jenkins	Extrêmement personnalisable, large écosystème de plugins	Déploiements complexes, environnements hybrides
GitLab CI/CD	Solution tout-en-un, intégration complète avec GitLab	Projets utilisant l'écosystème GitLab
CircleCI	Performance, mise en cache avancée, workflows complexes	Projets nécessitant des builds rapides et fréquents
Travis CI	Simplicité, support multi-OS et multi-language	Projets open-source, tests multi-environnements