注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
はじめに
このガイドは、Gradleビルドシステ� を使ってJavaのプロジェクトのための継続的インテグレーション(CI)を実行するワークフローを作成する方法を紹介します。 作成するワークフローによって、プルリクエストに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 CI ワークフローを拡張して、ワークフロー実行による成果物をアップロードできます。
GitHub ホステッド ランナーにはツール キャッシュとプレインストールされたソフトウェアがあり、それには Java Development Kit (JDK) と Gradle が含まれます。 JDK と Gradle に関するソフトウェアとプレインストールされたバージョンの一覧については、「GitHub ホステッド ランナーの仕様」を参照してく� さい。
前提条件
YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳細については、次を参照してく� さい。
Java及びGradleフレー� ワークの基本的な理解をしておくことをおすすめします。 詳細については、Gradle のドキュメントの使用開始に関するページを参照してく� さい。
GitHub Enterprise Server上でのセルフホストランナーの利用
GitHub Enterprise Server でセルフホスト ランナーと合わせてセットアップ アクション (actions/setup-LANGUAGE
など) を使用するときに、インターネットにアクセスできないランナー上にツール キャッシュを設定する必要がある� �合があります。 詳細については、「インターネットにアクセスできないセルフホスト ランナーにツール キャッシュを設定する」を参照してく� さい。
Gradle スターター ワークフローの使用
GitHub には、ほとんどの Gradle ベースの Java プロジェクトで動作する Gradle スターター ワークフローが用意されています。 詳細については、「Gradle スターター ワークフロー」を参照してく� さい。
� 早く始めるには、新しいワークフローを作成するときに事前構成済みの Gradle スターター ワークフローを選択できます。 詳細については、GitHub Actions クイックスタートに関するページを参照してく� さい。
リポジトリの .github/workflows
ディレクトリに新しいファイルを作成することにより、手作業でこのワークフローを追� することもできます。
# このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# ドキュメントを参照してく� さい。
# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。
# 新しいバージョンを取得するには、SHA を更新する必要があります。
# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。
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: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
with:
arguments: build
このワークフローは以下のステップを実行します。
checkout
ステップでは、ランナーにリポジトリのコピーがダウンロードされます。setup-java
ステップでは、Adoptium で Java 11 JDK が構成されます。- "Validate Gradle wrapper" ステップでは、ソース ツリーにある Gradle Wrapper JAR ファイルのチェックサ� が検証されます。
- "Build with Gradle" ステップでは、Gradle 組織が GitHub で提供する
gradle/gradle-build-action
アクションを使用してビルドが行われます。 このアクションでは、Gradle の呼び出し、結果の収集、ジョブ間の状態のキャッシュが処理されます。 詳細については、「gradle/gradle-build-action
」を参照してく� さい。
既定のスターター ワークフローは、ビルドとテストのワークフローを構築するときに適した出発点であり、プロジェクトの要求に合わせてこのスターター ワークフローをカスタマイズできます。
様々なオペレーティングシステ� 上での実行
スターター ワークフローは、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
アクション」を参照してく� さい。
コードのビルドとテスト
ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。
スターター ワークフローでは、既定で build
タスクが実行されます。 デフォルトのGradleの設定では、このコマンドは依存関係をダウンロードし、クラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージします。
プロジェクトのビルドに異なるコマンドを使ったり、異なるタスクを使いたいのであれば、それらを指定できます。 たとえば、ci.gradle ファイルで構成されている package
タスクを実行できます。
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Run the Gradle package task
uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
with:
arguments: -b ci.gradle package
成果物としてのワークフローのデータのパッケージ化
ビルドが成功し、テストがパスした後には、結果のJavaのパッケージをビルドの成果物としてアップロードすることになるかもしれません。 そうすれば、ビルドされたパッケージをワークフローの実行の一部として保存することになり、それらをダウンロードできるようになります。 成果物によって、Pull Requestをマージする前にローカルの環境でテスト及びデバッグしやすくなります。 詳細については、「アーティファクトを使用してワークフロー データを永続化する」を参照してく� さい。
Gradle では、通常、JAR、EAR、WAR のような出力ファイルが build/libs
ディレクトリに作成されます。 upload-artifact
アクションを使用して、そのディレクトリの内容をアップロードできます。
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
with:
arguments: build
- uses: actions/upload-artifact@v2
with:
name: Package
path: build/libs