Какие задачи выполняются при сборке проекта с помощью Gradle?

Основные задачи, выполняемые при сборке проекта с помощью Gradle

Gradle — это мощный инструмент для автоматизации сборки, который использует гибкую, декларативную модель на основе Directed Acyclic Graph (DAG) задач. При запуске сборки (например, командами gradle build, gradle test) выполняются последовательности задач, определяемые плагинами, зависимостями между задачами и конфигурацией в файлах build.gradle(.kts).

1. Инициализация и конфигурация

• Инициализация проекта: Gradle определяет, является ли проект многомодульным, находит корневой и дочерние проекты, создает объекты Project.
• Загрузка скриптов: Читаются файлы build.gradle (Groovy) или build.gradle.kts (Kotlin), а также settings.gradle, определяющие структуру.
• Применение плагинов: Активные плагины (например, java, application, spring-boot) добавляют свои задачи и конфигурации. Пример:

plugins {
    id("java")
    id("org.springframework.boot") version "3.1.5"
}

2. Фаза конфигурации задач

• Создание графа задач: Gradle определяет все задачи, их зависимости и порядок выполнения, но НЕ выполняет их.
• Конфигурация свойств: Задачи настраиваются через их свойства (например, исходные директории, выходные пути).
• Пример настройки задачи compileJava:

tasks.compileJava {
    sourceCompatibility = "17"
    targetCompatibility = "17"
    options.encoding = "UTF-8"
}

3. Фаза выполнения задач (на примере типичного Java-проекта)

Задачи выполняются в порядке, определенном графом зависимостей. Для проекта с плагином java, команда gradle build обычно запускает:

• Очистка (при необходимости):

  • clean — удаляет директорию build для полной пересборки.

• Компиляция:

  • compileJava — компилирует Java-исходники (src/main/java) в байт-код в build/classes/java/main.
  • compileTestJava — компилирует тесты (src/test/java) в build/classes/java/test.
  • Обработка ресурсов: Копирование ресурсов (src/main/resources, src/test/resources) в соответствующие выходные директории.

• Тестирование:

  • test — запускает юнит-тесты (например, с использованием JUnit или TestNG) и генерирует отчеты в build/reports/tests.

• Создание артефактов:

  • jar — упаковывает скомпилированные классы и ресурсы в JAR-файл (build/libs/project.jar).
  • war (для веб-приложений) — создает WAR-архив.
  • assemble — собирает все артефакты проекта (без запуска тестов).

• Дополнительные задачи (зависят от плагинов):

  • Статический анализ: checkstyleMain, pmdMain — проверка кода.
  • Генерация документации: javadoc — создает JavaDoc.
  • Обработка зависимостей: dependencies — выводит дерево зависимостей.

4. Задачи, специфичные для QA Automation

В проектах автоматизации тестирования часто добавляются плагины и задачи для:

• Управления тестовыми средами:

  task startTestContainers(type: Exec) {
    commandLine 'docker-compose', '-f', 'docker-compose.test.yml', 'up', '-d'
  }
  

• Запуска интеграционных или end-to-end тестов:

  tasks.register<Test>("integrationTest") {
    useJUnitPlatform()
    filter {
        includeTestsMatching("*IntegrationTest")
    }
    dependsOn(tasks.testClasses)
  }
  

• Генерации отчетов:

  • Плагин jacoco добавляет задачи jacocoTestReport для анализа покрытия кода.
  • Кастомные задачи для генерации Allure-отчетов.

• Упаковки автотестов в Docker-образ с помощью плагина com.bmuschko.docker-java-application.

5. Кэширование и инкрементальность

Одно из ключевых преимуществ Gradle — инкрементальная сборка. Если исходный код или ресурсы не менялись, задачи (например, compileJava) пропускаются, используя результаты предыдущих запусков из кэша. Это значительно ускоряет сборку в больших проектах.

Пример графа задач для команды gradle build (Java-проект):

:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources
:testClasses
:test
:check
:build

Заключение

Таким образом, Gradle выполняет не просто «сборку кода», а полный жизненный цикл проекта: от инициализации и конфигурации до компиляции, тестирования, создания артефактов и генерации отчетов. В QA Automation мы активно используем эту гибкость для создания кастомных задач (например, для прогона специфичных наборов тестов, подготовки данных или развертывания тестовых стендов), что делает Gradle незаменимым инструментом в CI/CD-пайплайнах.