Создание и тестирование Java с помощью Gradle

Введение

В этом руководстве показано, как создать рабочий процесс с непрерывной интеграцией (CI) для вашего Java-проекта с использованием системы сборки Gradle. Создаваемый рабочий процесс позволит увидеть, когда фиксации в запросе на вытягивание вызывают сбои в сборке или тестировании ветви по умолчанию; этот подход поможет убедиться, что ваш код всегда работоспособен. Рабочий процесс CI можно расширить для кэширования файлов и отправки артефактов из запуска рабочего процесса.

GitHub размещённые раннеры имеют кэш инструментов с предустановленным программным обеспечением, включающим Java Development Kits (JDK) и Gradle. Список программного обеспечения и предварительно установленных версий JDK и Gradle см. в разделе Средства выполнения тестов, размещенные в GitHub.

Необходимые компоненты

Требуются знания YAML и синтаксиса GitHub Actions. Дополнительные сведения см. в разделе:

• Синтаксис рабочего процесса для GitHub Actions
• Написание рабочих процессов

Рекомендуем иметь базовое понимание Java и фреймворка Gradle. Дополнительные сведения см. в руководстве пользователя Gradle.

Использование локальных средств выполнения тестов для GitHub Enterprise Server

При использовании действий установки (таких как actions/setup-LANGUAGE) в GitHub Enterprise Server с использованием локальных средств выполнения тестов может потребоваться настроить в них кэш инструментов, у которых отсутствует доступ к Интернету. Дополнительные сведения см. в разделе Настройка кэша инструментов для локально размещенных средств выполнения без доступа к Интернету.

Использование шаблона рабочего процесса Gradle

Чтобы быстро приступить к работе, добавьте шаблон рабочего процесса в .github/workflows каталог репозитория.

GitHub предоставляет шаблон рабочего процесса для Gradle, который должен работать для большинства Java с проектами Gradle. В последующих разделах этого руководства приведены примеры настройки этого шаблона рабочего процесса.

1. На GitHubперейдите на главную страницу репозитория. данных repositories.repositories.actions-tab %} 1. Если в вашем репозитории уже используется рабочий процесс, нажмите кнопку Создать рабочий процесс.

2. На странице "Выбор рабочего процесса" показан выбор рекомендуемых шаблонов рабочих процессов. Поискайте «Java with Gradle».

3. В рабочем процессе «Java с Gradle» нажмите Configure.

   Если вы не нашли шаблон рабочего процесса «Java с Gradle», скопируйте следующий код рабочего процесса в новый файл под названием gradle.yml в каталоге .github/workflows вашего репозитория.

   YAML

   # Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
   # Они предоставляются сторонним поставщиком, и на них распространяются
   # отдельные условия обслуживания, политика конфиденциальности и поддержка
   # документации.
   name: Java CI with Gradle
   
   on:
     push:
       branches: [ "main" ]
     pull_request:
       branches: [ "main" ]
   
   permissions:
     contents: read
   
   jobs:
     build:
       runs-on: ubuntu-latest
       steps:
       - uses: actions/checkout@v5
       - name: Set up JDK 17
         uses: actions/setup-java@v4
         with:
           java-version: '17'
           distribution: 'temurin'
   
       - name: Setup Gradle
         uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2
   
       - name: Build with Gradle
         run: ./gradlew build
   

Этот рабочий процесс выполняет следующие действия:

1. Извлекает копию репозитория проекта.

2. Настраивает JDK Java.

3. Настраивает среду Gradle. Действие gradle/actions/setup-gradle заботится о состоянии кэширования между выполнением рабочего процесса и содержит подробную сводку по всем выполнениям Gradle.

4. Шаг "Сборка с Gradle" выполняет build задачу с помощью оболочки Gradle.

5. Измените рабочий процесс по мере необходимости. Например, измените версию Java.

   Примечание.

   • Этот шаблон рабочего процесса содержит действие, которое не сертифицировано GitHub. Действия, предоставляемые сторонними сторонами, регулируются отдельными условиями обслуживания, политикой конфиденциальности и документацией по поддержке.
   • При использовании действий со стороны сторонних производителей следует использовать версию, указанную с помощью фиксации SHA. Если действие будет изменено и вы хотите использовать более новую версию, необходимо обновить SHA. Вы можете указать версию, ссылаясь на тег или ветвь, однако действие может измениться без предупреждения. Дополнительные сведения см. в разделе Справочник по безопасному использованию.

6. Щелкните Зафиксировать изменения.

Указание версии и архитектуры Java

Шаблон рабочего процесса настраивает PATH содержащий OpenJDK 8 для платформы x64. Если вы хотите использовать другую версию Java или выбрать другую архитектуру (x64 или x86), можно использовать действие setup-java для выбора другой среды выполнения Java.

Например, чтобы использовать JDK версии 11, предоставляемой Adoptium для платформы x64, можно выполнить действие setup-java и установить параметры java-version,distribution и architecture на '11', 'temurin' и x64.

steps:
  - uses: actions/checkout@v5
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v4
    with:
      java-version: '11'
      distribution: 'temurin'
      architecture: x64

steps:
  - uses: actions/checkout@v5
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v4
    with:
      java-version: '11'
      distribution: 'temurin'
      architecture: x64

Дополнительные сведения см. в описании действия setup-java.

Создание и тестирование кода

Вы можете использовать те же команды, которые используются для создания и тестирования кода в локальной среде.

Шаблон рабочего процесса будет выполнять build задачу по умолчанию. В конфигурации Gradle по умолчанию эта команда скачивает зависимости, выполняет сборку классов, проводит тесты и упаковывает классы в распространяемый формат, например в JAR-файл.

Если вы используете другие команды для сборки проекта или хотите выполнить другую задачу, это можно указать. Например, может потребоваться выполнить задачу, настроенную package в файле ci.gradle .

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-java@v4
    with:
      java-version: '17'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2

  - name: Build with Gradle
    run: ./gradlew -b ci.gradle package

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-java@v4
    with:
      java-version: '17'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2

  - name: Build with Gradle
    run: ./gradlew -b ci.gradle package

Кэширование зависимостей

Зависимости сборки можно кэшировать, чтобы ускорить выполнение рабочего процесса. После успешного выполнения gradle/actions/setup-gradle кэширует важные части домашнего каталога пользователя Gradle. При последующих запусках заданий данные из кэша восстанавливаются, так что скрипты сборки не нужно перекомпилировать, а зависимости не нужно скачивать из удаленных репозиториев пакетов.

При использовании действия gradle/actions/setup-gradle кэширование включено по умолчанию. Дополнительные сведения см. в статье gradle/actions/setup-gradle.

Упаковка данных рабочего процесса в виде артефактов

После успешной работы сборки и прохождения тестов, возможно, стоит загрузить полученные пакеты Java как артефакт сборки. Полученные пакеты будут храниться как часть выполнения рабочего процесса и их можно будет скачать. Артефакты помогут вам протестировать и отладить запросы на вытягивание в локальной среде до их слияния. Дополнительные сведения см. в разделе Хранение и предоставление общего доступа к данным с артефактами рабочего процесса.

Как правило, Gradle создает выходные файлы, такие как JAR, EAR или WAR, в каталоге build/libs. Содержимое этого каталога можно передать с помощью действия upload-artifact.

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-java@v4
    with:
      java-version: '17'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2

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

  - name: Upload build artifacts
    uses: actions/upload-artifact@v3
    with:
      name: Package
      path: build/libs

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
steps:
  - uses: actions/checkout@v5
  - uses: actions/setup-java@v4
    with:
      java-version: '17'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2

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

  - name: Upload build artifacts
    uses: actions/upload-artifact@v3
    with:
      name: Package
      path: build/libs