Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。 最新の情報については、「英語のドキュメント」を参照してください。
All products
GitHub のアクション

GradleでのJavaのビルドとテスト

この記事の内容

GitHub Actions中で継続的インテグレーション（CI）ワークフローを作成し、GradleでJavaのプロジェクトのビルドとテストを行うことができます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

はじめに

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

GitHub ホステッド ランナーにはツール キャッシュとプレインストールされたソフトウェアがあり、それには Java Development Kit (JDK) と Gradle が含まれます。 JDK と Gradle に関するソフトウェアとプレインストールされたバージョンの一覧については、「GitHub ホステッド ランナーの概要」を参照してください。

前提条件

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

Java及びGradleフレームワークの基本的な理解をしておくことをおすすめします。 詳細については、Gradle のドキュメントの使用開始に関するページを参照してください。

GitHub Enterprise Server上でのセルフホストランナーの利用

GitHub Enterprise Server でセルフホスト ランナーと合わせてセットアップ アクション (actions/setup-LANGUAGE など) を使用するときに、インターネットにアクセスできないランナー上にツール キャッシュを設定する必要がある場合があります。 詳しくは、「インターネットにアクセスできないセルフホストランナーにツールキャッシュを設定する」を参照してください。

Gradle スターター ワークフローの使用

GitHub には、ほとんどの Gradle ベースの Java プロジェクトで動作する Gradle スターター ワークフローが用意されています。 詳細については、「Gradle スターター ワークフロー」を参照してください。

素早く始めるには、新しいワークフローを作成するときに事前構成済みの Gradle スターター ワークフローを選択できます。 詳しくは、「GitHub Actions のクイックスタート」をご覧ください。

リポジトリの .github/workflows ディレクトリに新しいファイルを作成することにより、手作業でこのワークフローを追加することもできます。

YAML
# このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# ドキュメントを参照してください。

# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。
# 新しいバージョンを取得するには、SHA を更新する必要があります。
# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。

name: Java CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        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

このワークフローは以下のステップを実行します。

  1. checkout ステップでは、ランナーにリポジトリのコピーがダウンロードされます。
  2. setup-java ステップでは、Eclipse Adoptium によって Eclipse Temurin (Java) 17 JDK が構成されます。
  3. "Validate Gradle wrapper" ステップでは、ソース ツリーにある Gradle Wrapper JAR ファイルのチェックサムが検証されます。
  4. "Build with Gradle" ステップでは、Gradle 組織が GitHub で提供する gradle/gradle-build-action アクションを使用してビルドが行われます。 このアクションでは、Gradle の呼び出し、結果の収集、ジョブ間の状態のキャッシュが処理されます。 詳細については、「gradle/gradle-build-action」を参照してください。

既定のスターター ワークフローは、ビルドとテストのワークフローを構築するときに適した出発点であり、プロジェクトの要求に合わせてこのスターター ワークフローをカスタマイズできます。

様々なオペレーティングシステム上での実行

スターター ワークフローは、GitHub ホスト ubuntu-latest ランナーを使って Linux 上で実行するジョブを設定します。 runs-on キーを変更すると、別のオペレーティング システムでジョブを実行するようにできます。 たとえば、GitHubホストのWindowsランナーを使うことができます。

runs-on: windows-latest

あるいはGitHubホストのmacOSランナーで実行させることもできます。

runs-on: macos-latest

Dockerコンテナ上でジョブを実行させたり、独自のインフラストラクチャ上で動作するセルフホストランナーを提供したりすることもできます。 詳しくは、「GitHub Actions のワークフロー構文」を参照してください。

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

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

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

YAML
steps:
  - uses: actions/checkout@v3
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'adopt'
      architecture: x64

詳細については、「setup-java アクション」を参照してください。

コードのビルドとテスト

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

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

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

YAML
steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-java@v3
    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

依存関係のキャッシング

ビルドの依存関係をキャッシュして、ワークフローの実行を高速化できます。 正常に実行されると、gradle/gradle-build-action によって Gradle ユーザー ホーム ディレクトリの重要な部分がキャッシュされます。 以降のジョブでは、キャッシュが復元されるので、ビルド スクリプトを再コンパイルする必要がなく、依存関係をリモート パッケージ リポジトリからダウンロードする必要がなくなります。

gradle/gradle-build-action アクションを使用しているときは、キャッシュが既定で有効になります。 詳細については、「gradle/gradle-build-action」を参照してください。

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

ビルドが成功し、テストがパスした後には、結果のJavaのパッケージをビルドの成果物としてアップロードすることになるかもしれません。 そうすれば、ビルドされたパッケージをワークフローの実行の一部として保存することになり、それらをダウンロードできるようになります。 成果物によって、Pull Requestをマージする前にローカルの環境でテスト及びデバッグしやすくなります。 詳しくは、「ワークフロー データを成果物として保存する」を参照してください。

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

YAML
steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-java@v3
    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@v3
    with:
      name: Package
      path: build/libs