CI/CD pour Java : configurations avancées de GitHub Actions

Introduction : des pipelines de base aux solutions industrielles

Un pipeline CI/CD de base pour un projet Java, c'est bien. Mais dans le développement réel, lorsque le projet s'étend à des dizaines de modules et que l'équipe est composée de plusieurs développeurs, un simple `mvn clean test` ne répond plus aux exigences. Des questions se posent : comment accélérer le build ? Comment tester sur différentes versions de JDK ? Comment organiser l'exécution parallèle des tests ? Comment publier automatiquement les artefacts sur Docker Hub ?

Dans cet article, nous allons aborder les techniques avancées de configuration de GitHub Actions pour les projets Java. Vous apprendrez à transformer votre pipeline d'une simple séquence linéaire d'étapes en un système puissant, parallélisé et optimisé d'intégration et de livraison continues.

1. Builds matriciels : tests sur plusieurs JDK et OS

L'une des tâches clés du CI est de garantir que votre code Java fonctionne sur toutes les plateformes prises en charge. Lancer manuellement des tests sur Windows, macOS et Linux avec différentes versions de JDK (11, 17, 21) est un luxe inabordable. GitHub Actions propose une solution élégante : les builds matriciels (matrix builds).

Comment ça fonctionne

Vous définissez une matrice de paramètres (versions de JDK, systèmes d'exploitation), et GitHub crée automatiquement un job distinct pour chaque combinaison. Tous s'exécutent en parallèle.

Exemple de configuration

name: Java CI Matrixon: [push, pull_request]

jobs:  build:    runs-on: ${{ matrix.os }}    strategy:      matrix:        os: [ubuntu-latest, windows-latest, macos-latest]        java: [11, 17, 21]        exclude:          - os: windows-latest            java: 21  # Exclure JDK 21 sur Windows s'il n'est pas supporté      fail-fast: false  # Ne pas arrêter les autres jobs en cas d'erreur sur l'un d'eux

    steps:      - uses: actions/checkout@v4      - name: Set up JDK ${{ matrix.java }}        uses: actions/setup-java@v4        with:          java-version: ${{ matrix.java }}          distribution: 'temurin'      - name: Build with Maven        run: mvn -B clean verify --file pom.xml

Points clés :

• strategy.matrix — définit les combinaisons de paramètres.
• exclude — permet d'exclure les combinaisons manifestement non fonctionnelles ou inutiles.
• fail-fast: false — si un job échoue, les autres continuent. Cela donne une image complète de la compatibilité.

2. Mise en cache des dépendances : accélérer le build de 2 à 3 fois

Chaque exécution de pipeline commence dans un environnement propre. Maven ou Gradle télécharge à nouveau toutes les dépendances depuis les dépôts. Cela peut prendre 3 à 5 minutes. La mise en cache résout ce problème en conservant le dossier ~/.m2/repository (pour Maven) ou ~/.gradle/caches (pour Gradle) entre les exécutions.

GitHub Actions fournit l'action intégrée actions/cache. La clé de cache est générée à partir du fichier de dépendances (pom.xml). Si le fichier n'a pas changé, le cache est restauré instantanément.

Exemple pour Maven

steps:  - uses: actions/checkout@v4

  - name: Cache Maven dependencies    uses: actions/cache@v3    with:      path: ~/.m2/repository      key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}      restore-keys: |        ${{ runner.os }}-maven-

  - name: Set up JDK 17    uses: actions/setup-java@v4    with:      java-version: '17'      distribution: 'temurin'

  - name: Build with Maven    run: mvn -B clean verify --file pom.xml

Important : La mise en cache doit être effectuée avant l'étape de build. La clé hashFiles('**/pom.xml') garantit que le cache est mis à jour uniquement en cas de modification des dépendances.

3. Exécution parallèle des tests et artefacts de build

Lorsque votre projet contient des centaines ou des milliers de tests, et