Skip to main content

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

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

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

はじめに

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

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

前提条件

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

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

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

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

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

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

素早く始めるには、新しいワークフローを作成するときに事前構成済みの Maven スターター ワークフローを選択できます。 詳細については、GitHub Actions クイックスタートに関するページを参照してください。

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

YAML
name: Java CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'adopt'
      - name: Build with Maven
        run: mvn --batch-mode --update-snapshots package

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

  1. checkout ステップでは、ランナーにリポジトリのコピーがダウンロードされます。
  2. setup-java ステップでは、Adoptium で Java 11 JDK が構成されます。
  3. "Build with Maven" ステップでは、Maven package ターゲットが非インタラクティブ モードで実行されて、コードをビルド、テストに合格し、パッケージを作成できるようになります。

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

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

スターター ワークフローは、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@v3
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'adopt'
      architecture: x64

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

コードのビルドとテスト

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

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

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

YAML
steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'adopt'
  - name: Run the Maven verify phase
    run: mvn --batch-mode --update-snapshots verify

依存関係のキャッシング

ワークフローの実行速度を上げるために、依存関係をキャッシュすることもできます。 実行に成功すると、ローカルの Maven リポジトリはキャッシュに格納されます。 その後のワークフローの実行では、キャッシュがリストアされ、依存関係をリモートのMavenリポジトリからダウンロードする必要がなくなります。 setup-java アクションを使用するだけで依存関係をキャッシュすることも、カスタム構成や高度な構成に対して cache アクションを使用することもできます。

YAML
steps:
  - uses: actions/checkout@v3
  - name: Set up JDK 11
    uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'adopt'
      cache: maven
  - name: Build with Maven
    run: mvn --batch-mode --update-snapshots verify

このワークフローでは、ランナーのホーム ディレクトリの .m2 ディレクトリにあるローカル Maven リポジトリの内容が保存されます。 キャッシュ キーは pom.xml ハッシュされた内容であるため、pom.xml を変更するとキャッシュは無効になります。

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

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

Maven では、通常、JAR、EAR、WAR のような出力ファイルが target ディレクトリに作成されます。 それらを成果物としてアップロードするために、アップロードする成果物を含む新しいディレクトリにそれらをコピーできます。 たとえば、staging というディレクトリを作成できます。 その後、upload-artifact アクションを使用して、そのディレクトリの内容をアップロードできます。

YAML
steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'adopt'
  - run: mvn --batch-mode --update-snapshots verify
  - run: mkdir staging && cp target/*.jar staging
  - uses: actions/upload-artifact@v3
    with:
      name: Package
      path: staging