注: 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
ディレクトリに新しいファイルを作成することにより、手作業でこのワークフローを追� することもできます。
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 package
このワークフローは以下のステップを実行します。
checkout
ステップでは、ランナーにリポジトリのコピーがダウンロードされます。setup-java
ステップでは、Adoptium で Java 11 JDK が構成されます。- "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
成果物としてのワークフローのデータのパッケージ化
ビルドが成功し、テストがパスした後には、結果の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