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

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

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

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

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

Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.


Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.

はじめに

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

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

必要な環境

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

Java及びAntフレームワークの基本的な理解をしておくことをおすすめします。 詳しい情報についてはApache Ant Manualを参照してください。

Using self-hosted runners on GitHub Enterprise Server

When using setup actions (such as actions/setup-LANGUAGE) on GitHub Enterprise Server with self-hosted runners, you might need to set up the tools cache on runners that do not have internet access. For more information, see "Setting up the tool cache on self-hosted runners without internet access."

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@v2
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8
      - name: Build with Ant
        run: ant -noinput -buildfile build.xml

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

  1. checkoutステップは、ランナーにリポジトリのコピーをダウンロードします。
  2. setup-javaステップは、Java 1.8 JDKを設定します。
  3. "Build with Ant"ステップは、build.xml中のデフォルトターゲットを非インタラクティブモードで実行します。

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

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

スターターワークフローテンプレートは、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に設定できます。

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

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

YAML
steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-java@v1
    with:
      java-version: 1.8
  - 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@v2
  - uses: actions/setup-java@v1
  - run: ant -noinput -buildfile build.xml
  - uses: actions/upload-artifact@v2
    with:
      name: Package
      path: build/jar

Did this doc help you?

Privacy policy

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.