ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

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

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

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Oneで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 For more information, see "GitHub's products."

ここには以下の内容があります:

Did this doc help you?

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.

GitHub Actions の支払いを管理する GitHubは、macOSランナーのホストにMacStadiumを使用しています。

はじめに

このガイドは、Gradleビルドシステムを使ってJavaのプロジェクトのための継続的インテグレーション(CI)を実行するワークフローを作成する方法を紹介します。 作成するワークフローによって、プルリクエストに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 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に新しいファイルを作成して、手作業でこのワークフローを追加することもできます。

name: Java CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Build with Gradle
        run: ./gradlew build

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

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

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

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

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

runs-on: windows-latest

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

runs-on: windows-latest

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

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

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

たとえば、x64プラットフォーム用のバージョン9.0.4のJDKを使いたい場合、 setup-javaアクションを使って java-version及びarchitectureパラメーターを'9.0.4'x64に設定できます。

steps:
  - uses: actions/checkout@v2
  - name: Set up JDK 9.0.4 for x64
    uses: actions/setup-java@v1
    with:
      java-version: '9.0.4'
      architecture: x64

詳しい情報についてはsetup-javaアクションを参照してください。

コードのビルドとテスト

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

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

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

steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-java@v1
    with:
      java-version: 1.8
  - name: Run the Gradle package task
    run: ./gradlew -b ci.gradle package

依存関係のキャッシング

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

steps:
  - uses: actions/checkout@v2
  - name: Set up JDK 1.8
    uses: actions/setup-java@v1
    with:
      java-version: 1.8
  - name: Cache Gradle packages
    uses: actions/cache@v2
    with:
      path: ~/.gradle/caches
      key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle') }}
      restore-keys: ${{ runner.os }}-gradle
  - name: Build with Gradle
    run: ./gradlew build

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

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

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

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

steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-java@v1
  - run: ./gradlew build
  - uses: actions/upload-artifact@v2
    with:
      name: Package
      path: build/libs

Did this doc help you?

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.