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

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

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub AEで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 詳しい情報については「GitHubの製品」を参照してください。

はじめに

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

GitHubホストランナーは、Java Development Kits(JDKs)及びGradleを含むプリインストールされたソフトウェアを伴うツールキャッシュを持ちます。 JDK および Gradle のソフトウェアとプリインストールされたバージョンのリストについては、「GitHub でホストされているランナーの仕様」を参照してください。

必要な環境

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

Java及びGradleフレームワークの基本的な理解をしておくことをおすすめします。 詳しい情報については、GradleのドキュメンテーションのGetting Startedを参照してください。

Gradleワークフローテンプレートで始める

GitHubは、ほとんどのGradleベースのJavaプロジェクトで使えるGradleワークフローテンプレートを提供しています。 詳しい情報については、Gradle ワークフローテンプレートを参照してください。

素早く始めるには、新しいワークフローを作成する際に事前設定されたGradleテンプレートを選択できます。 詳しい情報については、「GitHub Actions のクイックスタート」を参照してください。

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

YAML
name: Java CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Set up JDK 11
        uses: actions/setup-java@v2
        with:
          java-version: '11'
          distribution: 'adopt'
      - name: Build with Gradle
        run: ./gradlew build

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

  1. checkoutステップは、ランナーにリポジトリのコピーをダウンロードします。
  2. setup-java ステップは、 Adoptium で Java 11 JDK を設定します。
  3. "Build with Gradle"ステップは、ラッパースクリプトのgradlewを実行し、コードがビルドされ、テストをパスし、パッケージが作成できることを保証します。

デフォルトのワークフローテンプレートは、ビルドとテストのワークフローを構築する際の素晴らしい出発点であり、プロジェクトの要求に合わせてこのテンプレートをカスタマイズできます。

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

スターターワークフローテンプレートは、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-versiondistributionarchitecture パラメータを'11''adopt'x64に設定できます。

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

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

YAML
steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-java@v2
    with:
      java-version: '11'
      distribution: 'adopt'
  - name: Run the Gradle package task
    run: ./gradlew -b ci.gradle package

依存関係のキャッシング

GitHubホストランナーを使用する場合、依存関係をキャッシュしてワークフローの実行を高速化できます。 実行に成功した後、ローカルのGradleパッケージキャッシュがGitHub Actionsのインフラストラクチャ上に保存されます。 その後のワークフローの実行では、キャッシュがリストアされ、依存関係をリモートのパッケージリポジトリからダウンロードする必要がなくなります。 詳しい情報については「ワークフローを高速化するための依存関係のキャッシング」及びcacheアクションを参照してください。

YAML
steps:
  - uses: actions/checkout@v2
  - name: Set up JDK 11
    uses: actions/setup-java@v2
    with:
      java-version: '11'
      distribution: 'adopt'
  - name: Cache Gradle packages
    uses: actions/cache@v2
    with:
      path: |
        ~/.gradle/caches
        ~/.gradle/wrapper
      key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
      restore-keys: |
        ${{ runner.os }}-gradle-
  - name: Build with Gradle
    run: ./gradlew build
  - name: Cleanup Gradle Cache
    # GitHub Actions でキャッシュされないように Gradle キャッシュからいくつかのファイルを削除
    # これらのファイルをGitHub Actionsのキャッシュからリストアすると、将来のビルドで問題が生じるかもしれない。
    run: |
      rm -f ~/.gradle/caches/modules-2/modules-2.lock
      rm -f ~/.gradle/caches/modules-2/gc.properties

このワークフローは、ランナーのホームディレクトリ内の.gradle/cachesディレクトリと.gradle/wrapperディレクトリにあるローカルのGradleパッケージキャッシュの内容を保存します。 キャッシュのキーはGradleのビルドファイル(Gradleのラッパー属性ファイルを含む)の内容のハッシュになるので、それらに変更があればキャッシュは無効になります。

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

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

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

YAML
steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-java@v2
    with:
      java-version: '11'
      distribution: 'adopt'

  - run: ./gradlew build
  - uses: actions/upload-artifact@v2
    with:
      name: Package
      path: build/libs

このドキュメントは役立ちましたか?プライバシーポリシー

これらのドキュメントを素晴らしいものにするのを手伝ってください!

GitHubのすべてのドキュメントはオープンソースです。間違っていたり、はっきりしないところがありましたか?Pull Requestをお送りください。

コントリビューションを行う

OR, コントリビューションの方法を学んでください。

問題がまだ解決していませんか?

GitHubコミュニティで質問するサポートへの連絡