Введение
В этом руководстве показано, как создать рабочий процесс, который выполняет непрерывную интеграцию (CI) для вашего проекта Java с помощью системы сборки Gradle. Создаваемый рабочий процесс позволит увидеть, когда фиксации в запросе на вытягивание вызывают сбои в сборке или тестировании ветви по умолчанию; этот подход поможет убедиться, что ваш код всегда работоспособен. Вы можете расширить рабочий процесс CI, чтобы передавать артефакты через выполнение рабочего процесса.
В локальных средствах выполнения следует установить требуемое программное обеспечение. Дополнительные сведения о локальных средствах выполнения см. в разделе Размещение собственных средств выполнения.
Предварительные требования
Требуются знания YAML и синтаксиса GitHub Actions. Дополнительные сведения см. в разделе:
Рекомендуется иметь базовое представление о Java и платформе Gradle. Дополнительные сведения см. в разделе Приступая к работе документации по Gradle.
Использование начального рабочего процесса Gradle
GitHub предоставляет начальный рабочий процесс Gradle, который будет работать для большинства проектов Java на базе Gradle. Дополнительные сведения см. в разделе Начальный рабочий процесс Gradle.
Чтобы быстро приступить к работе, при создании рабочего процесса можно выбрать предварительно настроенный начальный рабочий процесс Gradle. Дополнительные сведения см. в кратком руководстве по GitHub Actions.
Этот рабочий процесс также можно добавить вручную, создав новый файл в каталоге .github/workflows
репозитория.
# <a name="this-workflow-uses-actions-that-are-not-certified-by-github"></a>Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# <a name="they-are-provided-by-a-third-party-and-are-governed-by"></a>Они предоставляются сторонним поставщиком, и на них распространяются
# <a name="separate-terms-of-service-privacy-policy-and-support"></a>отдельные условия обслуживания, политика конфиденциальности и поддержка
# <a name="documentation"></a>документации.
# <a name="github-recommends-pinning-actions-to-a-commit-sha"></a>GitHub рекомендует закрепить действия в фиксации SHA.
# <a name="to-get-a-newer-version-you-will-need-to-update-the-sha"></a>Чтобы получить более новую версию, потребуется обновить SHA.
# <a name="you-can-also-reference-a-tag-or-branch-but-the-action-may-change-without-warning"></a>Вы также можете ссылаться на тег или ветвь, однако действие может измениться без предупреждения.
name: Java CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 17
uses: actions/setup-java@v2
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
with:
arguments: build
Этот рабочий процесс выполняет следующие действия:
- На шаге
checkout
в средство выполнения скачивается копия репозитория. - На
setup-java
этом шаге настраивается Eclipse Temurin (Java) JDK 17 от Eclipse Adoptium. - На шаге "Проверка программы-оболочки Gradle" проверяются контрольные суммы JAR-файлов программы-оболочки Gradle, имеющихся в исходном дереве.
- На шаге "Сборка с помощью Gradle" выполняется сборка с помощью действия
gradle/gradle-build-action
, предоставленного организацией Gradle на GitHub. Это действие отвечает за вызов Gradle, сбор результатов и кэширование состояния между заданиями. Дополнительные сведения см. на веб-сайтеgradle/gradle-build-action
.
Начальные рабочие процессы по умолчанию — это отличные отправные точки при создании рабочего процесса сборки и тестирования, а также начальный рабочий процесс можно настроить в соответствии с потребностями проекта.
Выполнение заданий в другой операционной системе
Начальный рабочий процесс настраивает задания для запуска в Linux с помощью размещенных в GitHub средств выполнения ubuntu-latest
. Можно изменить ключ runs-on
для выполнения заданий в другой операционной системе. Например, можно использовать размещенные в GitHub средства выполнения Windows.
runs-on: windows-latest
Кроме этого, можно выполнять задания на размещенных в GitHub средствах выполнения macOS.
runs-on: macos-latest
Можно также выполнять задания в контейнерах Docker или предоставить локальное средство выполнения, которое выполняется в собственной инфраструктуре. Дополнительные сведения см. в статье Синтаксис рабочего процесса для GitHub Actions.
Указание версии и архитектуры JVM
Начальный рабочий процесс настраивает PATH
, чтобы содержать OpenJDK 8 для платформы x64. Если вы хотите использовать другую версию Java или выбрать другую архитектуру (x64
или x86
), можно использовать действие setup-java
для выбора другой среды выполнения Java.
Например, чтобы использовать JDK версии 11, предоставляемой Adoptium для платформы x64, можно выполнить действие setup-java
и установить параметры java-version
,distribution
и architecture
на '11'
, 'adopt'
и x64
.
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11 for x64
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
architecture: x64
Дополнительные сведения см. в описании действия setup-java
.
Создание и тестирование кода
Вы можете использовать те же команды, которые используются для создания и тестирования кода в локальной среде.
Начальный рабочий процесс будет по умолчанию запускать задачу build
. В конфигурации Gradle по умолчанию эта команда скачивает зависимости, выполняет сборку классов, проводит тесты и упаковывает классы в распространяемый формат, например в JAR-файл.
Если вы используете другие команды для сборки проекта или хотите выполнить другую задачу, это можно указать. Например, может понадобиться выполнить задачу package
, настроенную в файле ci.gradle.
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Run the Gradle package task
uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
with:
arguments: -b ci.gradle package
Упаковка данных рабочего процесса в виде артефактов
После успешной сборки и прохождения тестов может потребоваться передать полученные пакеты Java в виде артефакта сборки. Полученные пакеты будут храниться как часть выполнения рабочего процесса и их можно будет скачать. Артефакты помогут вам протестировать и отладить запросы на вытягивание в локальной среде до их слияния. Дополнительные сведения см. в разделе Сохранение данных рабочего процесса с помощью артефактов.
Как правило, Gradle создает выходные файлы, такие как JAR, EAR или WAR, в каталоге build/libs
. Содержимое этого каталога можно передать с помощью действия upload-artifact
.
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
with:
arguments: build
- uses: actions/upload-artifact@v2
with:
name: Package
path: build/libs