CI/CD pour projets Kotlin : GitHub Actions de A à Z

Introduction : Pourquoi CI/CD est crucial pour les projets Kotlin

Dans le développement moderne en Kotlin, que ce soit pour un backend avec Ktor, une application Android ou un projet multiplateforme, l'exécution manuelle d'opérations répétitives (compilation, exécution des tests, vérification du style de code) est non seulement une perte de temps, mais aussi une source d'erreurs. CI/CD (Continuous Integration / Continuous Deployment) résout ce problème en automatisant l'ensemble du pipeline, du commit à la production.

GitHub Actions est un outil d'automatisation intégré qui convient parfaitement aux projets Kotlin. Il permet de créer des pipelines directement dans le dépôt, sans nécessiter de services tiers. Dans cet article, nous allons voir comment configurer un CI/CD complet pour Kotlin en utilisant GitHub Actions, de la compilation de base au déploiement.

1. Bases de GitHub Actions et Kotlin

GitHub Actions fonctionne sur la base de workflows — des fichiers YAML qui définissent une séquence d'étapes. Chaque workflow est déclenché par un événement (push, pull request, planification) et s'exécute dans un environnement virtuel runner.

Pour les projets Kotlin, la pile standard comprend :

\n
• Gradle ou Maven — système de compilation ;
\n
• JUnit / Kotest — frameworks de test ;
\n
• Detekt / ktlint — linters pour Kotlin.
\n

La première étape consiste à créer le fichier .github/workflows/ci.yml à la racine du dépôt. Examinons une configuration minimale pour la compilation et les tests.

1.1 Compilation et tests de base

Commençons par un pipeline simple qui se déclenche à chaque push et pull request sur la branche main :

name: CI for Kotlin\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v3\n      - name: Set up JDK 17\n        uses: actions/setup-java@v3\n        with:\n          java-version: '17'\n          distribution: 'temurin'\n      - name: Grant execute permission for gradlew\n        run: chmod +x gradlew\n      - name: Build with Gradle\n        run: ./gradlew build\n      - name: Run tests\n        run: ./gradlew test

Ce code fait ce qui suit : clone le dépôt, installe JDK 17 (version recommandée pour Kotlin 1.9+), rend gradlew exécutable, effectue la compilation et exécute les tests. Si les tests échouent, le pipeline s'arrête avec une erreur.

2. Configuration avancée : linting, mise en cache et matrice de compilation

La configuration de base est bien, mais pour un projet réel, il en faut plus. Ajoutons la vérification du style de code avec Detekt et la mise en cache des dépendances Gradle pour accélérer le travail.

2.1 Mise en cache de Gradle

Sans mise en cache, chaque exécution télécharge les dépendances à nouveau, ce qui peut prendre 2 à 5 minutes. Utilisons la mise en cache intégrée :

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

2.2 Linting avec Detekt

Ajoutons une tâche pour vérifier le code. Detekt peut être exécuté via le plugin Gradle :

- name: Run Detekt\n  run: ./gradlew detekt

Si Detekt trouve des violations, le pipeline se termine par une erreur. Cela garantit qu'aucun code "sale" n'entre dans le dépôt.

2.3 Matrice de compilation (Matrix Build)

Si votre projet prend en charge plusieurs versions de Kotlin ou JDK, utilisez une matrice. Cela permet de vérifier la compatibilité sans dupliquer le code :

jobs:\n  build:\n    strategy:\n      matrix:\n        java: [11, 17, 21]\n        kotlin: [1.9.0, 2.0.0]\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Set up JD