CI/CD для Kotlin проектов на GitHub Actions: полное руководство

Введение: Почему CI/CD критически важен для Kotlin-проектов

Современная разработка на Kotlin — будь то backend на Spring Boot, Android-приложение или мультиплатформенный проект — требует быстрого и надёжного цикла поставки. Ручные процессы сборки и тестирования не только отнимают время, но и чреваты ошибками. Здесь на помощь приходит CI/CD (Continuous Integration / Continuous Deployment).

GitHub Actions — это встроенная система автоматизации, которая позволяет запускать рабочие процессы (workflows) прямо в вашем репозитории. Для Kotlin-проектов это идеальный выбор: он легко интегрируется с Gradle, поддерживает кэширование зависимостей и позволяет разворачивать приложения на любых платформах.

В этой статье мы разберём, как настроить полноценный CI/CD пайплайн для Kotlin-проекта с использованием GitHub Actions: от базовой сборки до автоматического деплоя.

1. Основы GitHub Actions: структура workflow

Каждый workflow в GitHub Actions — это YAML-файл, лежащий в директории .github/workflows/. Рассмотрим базовые компоненты на примере Kotlin-проекта.

1.1. Триггеры (on)

Workflow запускается по определённым событиям: push в ветку, создание Pull Request, или по расписанию (cron).

1.2. Jobs и Steps

Job — это набор шагов, выполняемых на одном виртуальном окружении. Steps могут запускать команды, скрипты или готовые actions из маркетплейса.

1.3. Пример минимального workflow

Создадим файл .github/workflows/ci.yml для Kotlin-проекта на 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

Этот пайплайн будет запускать сборку и тесты при каждом push или PR в main/develop.

2. Оптимизация CI: кэширование и параллельные задачи

Без оптимизации каждый запуск будет заново скачивать зависимости Gradle. Для Kotlin-проектов это может занимать 2–5 минут. Решение — кэширование.

2.1. Кэширование Gradle-кэша

GitHub Actions позволяет кэшировать директорию ~/.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-

После первого запуска последующие будут использовать кэш — скорость увеличивается в 2–3 раза.

2.2. Параллельные jobs для разных задач

Можно разделить тестирование, линтинг и сборку на отдельные job, которые выполняются параллельно:

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

Здесь build запустится только после успешного прохождения линтинга и тестов.

3. Продвинутые сценарии для Kotlin-проектов

Рассмотрим реальные задачи, которые часто встречаются при CI/CD для Kotlin.

3.1. Публикация артефактов в GitHub Packages

Если вы разрабатываете библиотеку на Kotlin, можно автоматически публиковать её в GitHub Packages при создании релиза:

name: Publish to GitHub Packages

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Publish package
        run: ./gradlew publish
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

3.2. Деплой Kotlin backend на сервер

Для деплоя Spring Boot приложения можно использовать SSH-действие. Пример с Docker:

deploy:
  runs-on: ubuntu-latest
  needs: build
  steps:
    - name: Deploy via SSH
      uses: appleboy/ssh-action@v1.0.3
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /opt/app
          docker-compose pull
          docker-compose up -d

Не забудьте добавить секреты (secrets) в настройках репозитория: HOST, USER, SSH_KEY.

3.3. Мультиплатформенная сборка (Kotlin Multiplatform)

Для KMP проектов можно запускать сборку под разные таргеты:

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]

    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Build all targets
        run: ./gradlew allTests

Матрица стратегий позволяет тестировать код на всех трёх ОС одновременно.

4. Лучшие практики и частые ошибки

Чтобы ваш CI/CD был стабильным и быстрым, следуйте этим рекомендациям.

4.1. Используйте Gradle Wrapper

Всегда коммитьте файлы gradlew и gradlew