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

はじめに

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

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

必要な環境

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

• GitHub Actionsのワークフロー構文
• 「GitHub Actions を学ぶ」

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

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

GitHub Enterprise Server上でセルフホストランナーと合わせてセットアップアクション（actions/setup-LANGUAGEのような）を使う場合、インターネットアクセスを持たないランナー上にツールキャッシュをセットアップする必要があるかもしれません。 詳しい情報については「インターネットアクセスを持たないセルフホストランナー上へのツールキャッシュのセットアップ」を参照してください。

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

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

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

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

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 Maven
        run: mvn --batch-mode --update-snapshots verify

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

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-version、distribution、architecture パラメータを'11'、'adopt'、x64に設定できます。

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アクションを参照してください。

コードのビルドとテスト

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

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

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

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

依存関係のキャッシング

GitHubホストランナーを使用する場合、依存関係をキャッシュしてワークフローの実行を高速化できます。 実行に成功した後、ローカルのMavenリポジトリがGitHub Actionsのインフラストラクチャ上に保存されます。 その後のワークフローの実行では、キャッシュがリストアされ、依存関係をリモートのMavenリポジトリからダウンロードする必要がなくなります。 You can cache dependencies simply using the setup-java action or can use cache action for custom and more advanced configuration.

steps:
  - uses: actions/checkout@v2
  - name: Set up JDK 11
    uses: actions/setup-java@v2
    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アクションを使ってアップロードできます。

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