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.
- For more information about upgrading to GitHub Enterprise Server 3.0 or later, see "Upgrading GitHub Enterprise Server."
- For more information about configuring GitHub Actions after you upgrade, see the documentation for GitHub Enterprise Server 3.0.
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.
はじめに
このガイドは、ソフトウェアプロジェクト管理ツールのMavenを使ってJavaのプロジェクトのための継続的インテグレーション(CI)を実行するワークフローを作成する方法を紹介します。 作成するワークフローによって、Pull Requestに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 CIワークフローを拡張して、ファイルをキャッシュし、ワークフローの実行による成果物をアップロードするようにもできます。
GitHubホストランナーは、Java Development Kits(JDKs)及びMavenを含むプリインストールされたソフトウェアを伴うツールキャッシュを持ちます。 JDK および Maven のソフトウェアとプリインストールされたバージョンのリストについては、「GitHub でホストされているランナーの仕様」を参照してください。
必要な環境
YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳しい情報については、以下を参照してください。
Java及びMavenフレームワークの基本的な理解をしておくことをおすすめします。 詳しい情報については、MavenのドキュメンテーションのMaven Getting Started Guideを参照してください。
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."
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 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Build with Maven
run: mvn --batch-mode --update-snapshots verify
このワークフローは以下のステップを実行します。
checkout
ステップは、ランナーにリポジトリのコピーをダウンロードします。setup-java
ステップは、Java 1.8 JDKを設定します。- "Build with Maven"ステップは、Mavenの
package
ターゲットを非インタラクティブモードで実行し、コードがビルドされ、テストをパスし、パッケージが作成できることを保証します。
デフォルトのワークフローテンプレートは、ビルドとテストのワークフローを構築する際の素晴らしい出発点であり、プロジェクトの要求に合わせてこのテンプレートをカスタマイズできます。
様々なオペレーティングシステム上での実行
スターターワークフローテンプレートは、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
に設定できます。
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
アクションを参照してください。
コードのビルドとテスト
ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。
スターターワークフローは、デフォルトでpackage
ターゲットを実行します。 デフォルトのMavenの設定では、このコマンドは依存関係をダウンロードし、クラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージします。
プロジェクトのビルドに異なるコマンドを使ったり、異なるターゲットを使いたいのであれば、それらを指定できます。 たとえば、pom-ci.xmlファイル中で設定されたverify
ターゲットを実行したいこともあるでしょう。
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Run the Maven verify phase
run: mvn --batch-mode --update-snapshots verify
依存関係のキャッシング
GitHubホストランナーを使用する場合、依存関係をキャッシュしてワークフローの実行を高速化できます。 実行に成功した後、ローカルのMavenリポジトリがGitHub Actionsのインフラストラクチャ上に保存されます。 その後のワークフローの実行では、キャッシュがリストアされ、依存関係をリモートのMavenリポジトリからダウンロードする必要がなくなります。 詳しい情報については「ワークフローを高速化するための依存関係のキャッシング」及びcache
アクションを参照してください。
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Cache Maven packages
uses: actions/cache@v2
with:
path: ~/.m2
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
restore-keys: ${{ runner.os }}-m2
- 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@v1
- run: mvn --batch-mode --update-snapshots verify
- run: mkdir staging && cp target/*.jar staging
- uses: actions/upload-artifact@v2
with:
name: Package
path: staging