Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2026-03-17. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

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

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

メモ

GitHub ホステッド ランナーは、現在 GitHub Enterprise Server ではサポートされていません。

はじめに

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

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

前提条件

YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳細については、以下を参照してください: * GitHub Actions のワークフロー構文 * ワークフローの書き込み

Javaと Gradle フレームワークの基本的な理解をお勧めします。 詳細については、「Gradle のユーザー マニュアル」を参照してください。

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

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

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

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

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

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

  2. リポジトリ名の下にある [ Actions] をクリックします。

    "github/docs" リポジトリのタブのスクリーンショット。 [アクション] タブがオレンジ色の枠線で強調表示されています。

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

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

  5. "Gradle を使用したJava" ワークフローで、Configure をクリックします。

    "Gradle でJava" ワークフロー テンプレートが見つからない場合は、次のワークフロー コードを、リポジトリの 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
    ```このワークフローは以下のステップを実行します。
    
    
  6. プロジェクトのリポジトリのコピーをチェックアウトします。

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

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

  9. "Build with Gradle" ステップでは、Gradle Wrapper を使用して、build タスクが実行されます。

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

    メモ

    • このワークフロー テンプレートでは、GitHub によって認定されていないアクションが使われます。 サード パーティによって提供されるアクションには、個別のサービス使用条件、プライバシー ポリシー、およびサポート ドキュメントが適用されます。
    • サード パーティのアクションを使用するには、コミット SHA で指定されたバージョンを使用する必要があります。 アクションが変更された新しいバージョンを使用する場合は、SHA を更新する必要があります。 タグまたはブランチを参照してバージョンを指定できますが、アクションは警告なしに変更される可能性があります。 詳しくは、「セキュリティで保護された使用に関するリファレンス」をご覧ください。
  11.        **[Commit changes]** をクリックします。
    

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

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

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

YAML
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ファイルのような配布可能なフォーマットにクラスをパッケージします。

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

YAML
# このワークフローは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`](https://github.com/gradle/actions/blob/main/setup-gradle/README.md#caching-build-state-between-jobs)」を参照してください。

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

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

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

YAML
# このワークフローは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