CI/CD pour les projets Kotlin sur GitHub Actions : guide complet

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

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

Le développement moderne en Kotlin — qu'il s'agisse d'un backend Spring Boot, d'une application Android ou d'un projet multiplateforme — nécessite un cycle de livraison rapide et fiable. Les processus manuels de build et de test prennent non seulement du temps, mais sont également sujets aux erreurs. C'est là que le CI/CD (Continuous Integration / Continuous Deployment) entre en jeu.

GitHub Actions est un système d'automatisation intégré qui permet d'exécuter des workflows directement dans votre dépôt. Pour les projets Kotlin, c'est un choix idéal : il s'intègre facilement avec Gradle, prend en charge la mise en cache des dépendances et permet de déployer des applications sur n'importe quelle plateforme.

Dans cet article, nous allons voir comment configurer un pipeline CI/CD complet pour un projet Kotlin en utilisant GitHub Actions : du build de base au déploiement automatique.

1. Les bases de GitHub Actions : structure d'un workflow

Chaque workflow dans GitHub Actions est un fichier YAML situé dans le répertoire .github/workflows/. Examinons les composants de base à l'aide d'un exemple de projet Kotlin.

1.1. Déclencheurs (on)

Un workflow est déclenché par des événements spécifiques : push vers une branche, création d'une Pull Request, ou selon un planning (cron).

1.2. Jobs et Steps

Un Job est un ensemble d'étapes exécutées dans un même environnement virtuel. Les Steps peuvent lancer des commandes, des scripts ou des actions prêtes à l'emploi depuis le marketplace.

1.3. Exemple de workflow minimal

Créons un fichier .github/workflows/ci.yml pour un projet Kotlin avec Gradle :

name: CI for Kotlin

on:  push:    branches: [ main, develop ]  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: Setup Gradle        uses: gradle/actions/setup-gradle@v3

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

      - name: Run tests        run: ./gradlew test

Ce pipeline exécutera le build et les tests à chaque push ou PR sur main/develop.

2. Optimisation du CI : mise en cache et tâches parallèles

Sans optimisation, chaque exécution téléchargera à nouveau les dépendances Gradle. Pour les projets Kotlin, cela peut prendre 2 à 5 minutes. La solution est la mise en cache.

2.1. Mise en cache du cache Gradle

GitHub Actions permet de mettre en cache le répertoire ~/.gradle/caches :

- 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-

Après la première exécution, les suivantes utiliseront le cache — la vitesse est multipliée par 2 à 3.

2.2. Jobs parallèles pour différentes tâches

Il est possible de séparer les tests, le linting et le build en différents jobs qui s'exécutent en parallèle :

jobs:  lint:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run detekt        run: ./gradlew detekt

  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run tests        run: ./gradlew test

  build:    needs: [lint, test]    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Build JAR        run: ./gradlew bootJar

Ici, build ne se lancera qu'après la réussite du linting et des tests.