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

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

はじめに

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

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

前提条件

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

Java及びAntフレームワークの基本的な理解をしておくことをおすすめします。詳細については、Apache Ant マニュアルを参照してください。

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

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

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

GitHub からはほとんどの Ant ベース Java プロジェクトで機能する Ant スターターワークフローが提供されます。詳細については、「Ant スターターワークフロー」を参照してください。

素早く始めるには、新しいワークフローを作成するときに事前構成済みの Ant スターターワークフローを選択できます。詳しくは、「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 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: Build with Ant
        run: ant -noinput -buildfile build.xml

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

checkout ステップでは、ランナーにリポジトリのコピーがダウンロードされます。
setup-java ステップでは、Eclipse Adoptium によって Eclipse Temurin (Java) 17 JDK が構成されます。
"Build with Ant" ステップは、build.xml 中のデフォルトターゲットを非インタラクティブモードで実行します。

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

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

スターターワークフローは、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 に設定します。

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

コードのビルドとテスト

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

このスターターワークフローは、build.xml ファイルで指定されたデフォルトのターゲットを実行します。デフォルトのターゲットは、一般的にクラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージするように設定されるでしょう。

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

YAML

steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-java@v3
    with:
      java-version: '17'
      distribution: 'temurin'
  - name: Run the Ant jar target
    run: ant -noinput -buildfile build-ci.xml jar

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

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

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

YAML

steps:
  - uses: actions/checkout@v3
  - uses: actions/setup-java@v3
    with:
      java-version: '17'
      distribution: 'temurin'
  
  - run: ant -noinput -buildfile build.xml
  - uses: actions/upload-artifact@v3
    with:
      name: Package
      path: build/jar

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

この記事の内容