# Gradle を使用したJavaの構築とテスト

Gradle を使用してJava プロジェクトをビルドしてテストするために、GitHub Actionsで継続的インテグレーション (CI) ワークフローを作成する方法について説明します。

## はじめに

このガイドでは、Gradle ビルド システムを使用して、Java プロジェクトの継続的インテグレーション (CI) を実行するワークフローを作成する方法について説明します。 作成するワークフローによって、プルリクエストに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 CIワークフローをキャッシュ ファイルに拡張して、ワークフローの実行による成果物をアップロードするようにもできます。

GitHub によってホストされるランナーには、Java Development Kits (JDK) および Gradle を含むプリインストール済みソフトウェアを保持しているツール キャッシュがあります。 JDK と Gradle に関するソフトウェアとプレインストールされたバージョンの一覧については、「[GitHub ホステッド ランナー](/ja/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)」を参照してください。

## 前提条件

YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳細については、以下を参照してください:

* [GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions)
* [ワークフローの書き込み](/ja/enterprise-cloud@latest/actions/learn-github-actions)

Javaと Gradle フレームワークの基本的な理解をお勧めします。 詳細については、「[Gradle のユーザー マニュアル](https://docs.gradle.org/current/userguide/userguide.html)」を参照してください。

## Gradle ワークフロー テンプレートの使用

すぐに開始するには、リポジトリの `.github/workflows` ディレクトリにワークフロー テンプレートを追加します。

GitHub には、Gradle プロジェクトでほとんどのJavaで機能する必要がある Gradle 用のワークフロー テンプレートが用意されています。 このガイドの以降のセクションでは、このワークフロー テンプレートをカスタマイズする方法の例を示します。

1. GitHub で、リポジトリのメイン ページに移動します。

2. リポジトリ名の下にある **\[<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-play" aria-label="play" role="img"><path d="M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm4.879-2.773 4.264 2.559a.25.25 0 0 1 0 .428l-4.264 2.559A.25.25 0 0 1 6 10.559V5.442a.25.25 0 0 1 .379-.215Z"></path></svg> Actions]** をクリックします。

   !["github/docs" リポジトリのタブのスクリーンショット。 \[アクション\] タブがオレンジ色の枠線で強調表示されています。](/assets/images/help/repository/actions-tab-global-nav-update.png)

3. ワークフローが既にリポジトリ内にある場合は、 **\[新しいワークフロー]** をクリックします。

4. \[ワークフローの選択] ページには、推奨されるワークフロー テンプレートの選択が表示されます。 "Gradle でJava" を検索します。

5. "Gradle を使用したJava" ワークフローで、**Configure** をクリックします。このワークフローは以下のステップを実行します。

6. プロジェクトのリポジトリのコピーをチェックアウトします。

7. Java JDKをセットアップします。

8. Gradle 環境を設定します。 [`gradle/actions/setup-gradle`](https://github.com/gradle/actions) アクションは 、ワークフロー実行間のキャッシュ状態を処理し、すべての Gradle 実行の詳細な概要を提供します。

9. "Build with Gradle" ステップでは、`build` を使用して、[](https://docs.gradle.org/current/userguide/gradle_wrapper.html) タスクが実行されます。

10. 必要に応じてワークフローを編集します。 たとえば、Javaバージョンを変更します。

    > \[!NOTE]
    >
    > * このワークフロー テンプレートでは、GitHub によって認定されていないアクションが使われます。 サード パーティによって提供されるアクションには、個別のサービス使用条件、プライバシー ポリシー、およびサポート ドキュメントが適用されます。
    > * サード パーティのアクションを使用するには、コミット SHA で指定されたバージョンを使用する必要があります。 アクションが変更された新しいバージョンを使用する場合は、SHA を更新する必要があります。 タグまたはブランチを参照してバージョンを指定できますが、アクションは警告なしに変更される可能性があります。 詳しくは、「[セキュリティで保護された使用に関するリファレンス](/ja/enterprise-cloud@latest/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)」をご覧ください。

11. ```
           **[Commit changes]** をクリックします。
    ```

`gradle.yml` ワークフロー ファイルが使用中リポジトリの `.github/workflows` ディレクトリに追加されます。

### Javaのバージョンとアーキテクチャの指定

ワークフロー テンプレートで x64 プラットフォーム用の OpenJDK 8 を含むように `PATH` を設定します。 異なるバージョンの Java を使用する場合、あるいは異なるアーキテクチャ (`x64` または `x86`) をターゲットとする場合、`setup-java` アクションを使って異なる Java ランタイム環境を選択できます。

たとえば、x64 プラットフォームに対して Adoptium によって提供される JDK のバージョン 11 を使用するには、`setup-java` アクションを使用して、`java-version`、`distribution`、`architecture` パラメーターを `'11'`、`'temurin'`、`x64` に設定します。

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

詳細については、「[`setup-java`](https://github.com/actions/setup-java) アクション」を参照してください。

## コードのビルドとテスト

ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。

ワークフロー テンプレートでは、既定で `build` タスクが実行されます。 デフォルトのGradleの設定では、このコマンドは依存関係をダウンロードし、クラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージします。

プロジェクトのビルドに異なるコマンドを使ったり、異なるタスクを使いたいのであれば、それらを指定できます。 たとえば、`package` ファイルで構成されている `ci.gradle` タスクを実行したいと思うかもしれません。

```yaml copy
# このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# ドキュメントを参照してください。
steps:
  - uses: actions/checkout@v6
  - 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`](https://github.com/gradle/actions/blob/main/setup-gradle/README.md#caching-build-state-between-jobs)」を参照してください。
```

## 成果物としてのワークフローのデータのパッケージ化

ビルドが成功し、テストが成功したら、結果のJava パッケージをビルド成果物としてアップロードできます。 そうすれば、ビルドされたパッケージをワークフローの実行の一部として保存することになり、それらをダウンロードできるようになります。 アーティファクトを利用して、Pull Requestをマージする前にローカル環境でテストとデバッグを行うことができます。 詳しくは、「[ワークフロー成果物を使ったデータの格納と共有](/ja/enterprise-cloud@latest/actions/using-workflows/storing-workflow-data-as-artifacts)」をご覧ください。

Gradle では、通常、JAR、EAR、WAR のような出力ファイルが `build/libs` ディレクトリに作成されます。
`upload-artifact` アクションを使用して、そのディレクトリの内容をアップロードできます。

```yaml copy
# このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# ドキュメントを参照してください。
steps:
  - uses: actions/checkout@v6
  - 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@v4
    with:
      name: Package
      path: build/libs
```