CI/CD pour les projets Kotlin avec GitHub Actions : guide étape par étape

Introduction : Pourquoi le CI/CD est indispensable pour le développement Kotlin

Le développement Kotlin moderne ne consiste pas seulement à écrire un code concis et sûr, mais aussi à assurer sa livraison continue. Que vous créiez une application côté serveur avec Ktor, une application Android ou un projet multiplateforme, les builds et les tests manuels deviennent rapidement un goulot d'étranglement. Le CI/CD (Intégration Continue / Déploiement Continu) automatise ces processus, réduisant le risque d'erreur humaine et accélérant la sortie de nouvelles fonctionnalités.

GitHub Actions est l'un des outils les plus populaires pour implémenter le CI/CD, surtout si votre code est déjà hébergé sur GitHub. Il s'intègre étroitement à l'écosystème Kotlin, prend en charge Gradle et Maven, et permet de configurer facilement des pipelines pour tous les besoins. Dans cet article, nous allons détailler comment mettre en place un cycle complet de build, de test et de déploiement d'un projet Kotlin en utilisant GitHub Actions.

Les bases de GitHub Actions : Structure d'un Workflow

Avant d'écrire du code, comprenons les concepts de base. Un workflow dans GitHub Actions est un processus automatisé qui est déclenché par un événement spécifique (par exemple, un push sur la branche principale). Un workflow est décrit dans un fichier YAML stocké dans le répertoire .github/workflows/ de votre dépôt.

Une structure typique de workflow comprend :

• name — le nom du workflow (affiché dans l'interface GitHub).
• on — les événements déclencheurs (par exemple, push, pull_request).
• jobs — un ensemble de tâches qui s'exécutent séquentiellement ou en parallèle.
• steps — les étapes au sein d'une tâche (configuration du JDK, mise en cache des dépendances, exécution des tests).

Pour les projets Kotlin, une étape clé consiste à configurer la version correcte du JDK (généralement 11, 17 ou 21) et à utiliser le Gradle Wrapper (./gradlew), ce qui garantit la reproductibilité du build sur n'importe quelle machine.

Étape 1 : Build et Test de base pour un projet Kotlin

Commençons par la chose la plus simple : un workflow qui exécute les tests à chaque push sur main ou lors de la création d'une Pull Request. C'est le fondement de tout CI/CD — s'assurer que le nouveau code ne casse pas les fonctionnalités existantes.

Créez un fichier .github/workflows/ci.yml avec le contenu suivant :

name: CI for Kotlin

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

jobs:  build:    runs-on: ubuntu-latest

    steps:      - uses: actions/checkout@v4

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

      - name: Grant execute permission for gradlew        run: chmod +x gradlew

      - name: Cache Gradle packages        uses: actions/cache@v4        with:          path: |            ~/.gradle/caches            ~/.gradle/wrapper          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}          restore-keys: |            ${{ runner.os }}-gradle-

      - name: Build with Gradle        run: ./gradlew build

      - name: Run tests        run: ./gradlew test

Détaillons les points clés :

• actions/checkout@v4 — clone le dépôt dans l'environnement d'exécution.
• actions/setup-java@v4 — installe JDK 17 (Temurin). Vous pouvez choisir une version différente si votre projet l'exige, par exemple JDK 11 ou 21.
• actions/cache@v4 — met en cache les dépendances Gradle. C'est crucial pour la rapidité : sans cache, chaque build devrait télécharger toutes les bibliothèques depuis le début (ce qui peut prendre 2 à 5 minutes). La mise en cache réduit cela à quelques secondes.
• ./gradlew build — un build complet du projet (compilation + tests). Si vous ne voulez que les tests, utilisez ./gradlew test.