CI/CD para projetos Kotlin: GitHub Actions do A ao Z

Introdução: Por que CI/CD é criticamente importante para projetos Kotlin

No desenvolvimento moderno com Kotlin, seja backend com Ktor, aplicativo Android ou projeto multiplataforma, a execução manual de operações repetitivas (compilação, execução de testes, verificação de estilo de código) não é apenas uma perda de tempo, mas também uma fonte de erros. CI/CD (Integração Contínua / Implantação Contínua) resolve esse problema automatizando todo o pipeline, do commit à produção.

GitHub Actions é uma ferramenta de automação integrada que é ideal para projetos Kotlin. Ela permite criar pipelines diretamente no repositório, sem exigir serviços de terceiros. Neste artigo, vamos abordar como configurar um CI/CD completo para Kotlin usando GitHub Actions, desde a compilação básica até a implantação.

1. Fundamentos do GitHub Actions e Kotlin

GitHub Actions funciona com base em workflows — arquivos YAML que definem uma sequência de etapas. Cada workflow é acionado por um gatilho (push, pull request, schedule) e executado em um ambiente virtual runner.

Para projetos Kotlin, a stack padrão inclui:

\n
• Gradle ou Maven — sistema de compilação;
\n
• JUnit / Kotest — frameworks de teste;
\n
• Detekt / ktlint — linters para Kotlin.
\n

O primeiro passo é criar o arquivo .github/workflows/ci.yml na raiz do repositório. Vamos considerar uma configuração mínima para compilação e teste.

1.1 Compilação e teste básicos

Vamos começar com um pipeline simples que é acionado a cada push e pull request na branch 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

Este código faz o seguinte: clona o repositório, instala o JDK 17 (versão recomendada para Kotlin 1.9+), torna o gradlew executável, realiza a compilação e executa os testes. Se os testes falharem, o pipeline para com erro.

2. Configuração avançada: linting, cache e matriz de compilações

A configuração básica é boa, mas para um projeto real é necessário mais. Vamos adicionar verificação de estilo de código com Detekt e cache de dependências do Gradle para acelerar o processo.

2.1 Cache do Gradle

Sem cache, cada execução baixa as dependências novamente, o que pode levar de 2 a 5 minutos. Usamos o cache integrado:

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

Vamos adicionar uma tarefa para verificar o código. O Detekt pode ser executado através do plugin do Gradle:

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

Se o Detekt encontrar violações, o pipeline será encerrado com erro. Isso garante que código "sujo" não entre no repositório.

2.3 Matriz de compilações (Matrix Build)

Se o seu projeto suporta várias versões do Kotlin ou JDK, use a matriz. Isso permite verificar a compatibilidade sem duplicar código:

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