CI/CD für Kotlin-Projekte: GitHub Actions von A bis Z

Einleitung: Warum CI/CD für Kotlin-Projekte entscheidend ist

In der modernen Kotlin-Entwicklung, sei es ein Backend mit Ktor, eine Android-App oder ein plattformübergreifendes Projekt, ist das manuelle Ausführen sich wiederholender Aufgaben (Bauen, Testen, Code-Stil-Prüfung) nicht nur Zeitverschwendung, sondern auch eine Fehlerquelle. CI/CD (Continuous Integration / Continuous Deployment) löst dieses Problem, indem es die gesamte Pipeline vom Commit bis zur Produktion automatisiert.

GitHub Actions ist ein integriertes Automatisierungstool, das sich ideal für Kotlin-Projekte eignet. Es ermöglicht die Erstellung von Pipelines direkt im Repository, ohne dass Drittanbieterdienste erforderlich sind. In diesem Artikel werden wir die Einrichtung einer vollständigen CI/CD-Pipeline für Kotlin mit GitHub Actions durchgehen, vom grundlegenden Bauen bis zum Deployment.

1. Grundlagen von GitHub Actions und Kotlin

GitHub Actions basiert auf Workflows – YAML-Dateien, die die Abfolge der Schritte definieren. Jeder Workflow wird durch einen Auslöser (Push, Pull Request, Zeitplan) gestartet und in einer virtuellen Runner-Umgebung ausgeführt.

Für Kotlin-Projekte umfasst der Standard-Stack:

\n
• Gradle oder Maven – Build-System;
\n
• JUnit / Kotest – Test-Frameworks;
\n
• Detekt / ktlint – Linter für Kotlin.
\n

Der erste Schritt ist die Erstellung der Datei .github/workflows/ci.yml im Stammverzeichnis des Repositorys. Betrachten wir eine minimale Konfiguration für das Bauen und Testen.

1.1 Grundlegendes Bauen und Testen

Beginnen wir mit einer einfachen Pipeline, die bei jedem Push und Pull Request in den main-Branch ausgelöst wird:

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

Dieser Code macht Folgendes: Er klont das Repository, installiert JDK 17 (empfohlene Version für Kotlin 1.9+), macht gradlew ausführbar, führt den Build aus und startet die Tests. Wenn Tests fehlschlagen, stoppt die Pipeline mit einem Fehler.

2. Erweiterte Konfiguration: Linting, Caching und Build-Matrix

Die grundlegende Einrichtung ist gut, aber für ein echtes Projekt wird mehr benötigt. Fügen wir eine Code-Stil-Prüfung mit Detekt und Caching von Gradle-Abhängigkeiten hinzu, um die Geschwindigkeit zu verbessern.

2.1 Gradle-Caching

Ohne Caching werden bei jedem Lauf die Abhängigkeiten erneut heruntergeladen, was 2-5 Minuten dauern kann. Verwenden wir das integrierte Caching:

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

Fügen wir eine Aufgabe zur Code-Prüfung hinzu. Detekt kann über das Gradle-Plugin ausgeführt werden:

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

Wenn Detekt Verstöße findet, wird die Pipeline mit einem Fehler beendet. Dies stellt sicher, dass kein "unsauberer" Code in das Repository gelangt.

2.3 Build-Matrix

Wenn Ihr Projekt mehrere Versionen von Kotlin oder JDK unterstützt, verwenden Sie eine Matrix. Dies ermöglicht die Überprüfung der Kompatibilität ohne Code-Duplizierung:

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