注: 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@v3
- name: Set up JDK 17
uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
- name: Build with Gradle
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: build
このワークフローは以下のステップを実行します。
checkout
ステップでは、ランナーにリポジトリのコピーがダウンロードされます。setup-java
ステップでは、Eclipse Adoptium によって Eclipse Temurin (Java) 17 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@v3
- name: Set up JDK 11 for x64
uses: actions/setup-java@v3
with:
java-version: '11'
distribution: 'adopt'
architecture: x64
詳細については、「setup-java
アクション」を参照してください。
コードのビルドとテスト
ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。
スターター ワークフローでは、既定で build
タスクが実行されます。 デフォルトのGradleの設定では、このコマンドは依存関係をダウンロードし、クラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージします。
プロジェクトのビルドに異なるコマンドを使ったり、異なるタスクを使いたいのであれば、それらを指定できます。 たとえば、ci.gradle ファイルで構成されている package
タスクを実行できます。
steps:
- uses: actions/checkout@v3
- uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
- name: Run the Gradle package task
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: -b ci.gradle package
依存関係のキャッシング
ビルドの依存関係をキャッシュして、ワークフローの実行を高速化できます。 正常に実行されると、gradle/gradle-build-action
によって Gradle ユーザー ホーム ディレクトリの重要な部分がキャッシュされます。 以降のジョブでは、キャッシュが復元されるので、ビルド スクリプトを再コンパイルする必要がなく、依存関係をリモート パッケージ リポジトリからダウンロードする必要がなくなります。
gradle/gradle-build-action
アクションを使用しているときは、キャッシュが既定で有効になります。 詳細については、「gradle/gradle-build-action
」を参照してください。
成果物としてのワークフローのデータのパッケージ化
ビルドが成功し、テストがパスした後には、結果のJavaのパッケージをビルドの成果物としてアップロードすることになるかもしれません。 そうすれば、ビルドされたパッケージをワークフローの実行の一部として保存することになり、それらをダウンロードできるようになります。 成果物によって、Pull Requestをマージする前にローカルの環境でテスト及びデバッグしやすくなります。 詳しくは、「ワークフロー データを成果物として保存する」を参照してください。
Gradle では、通常、JAR、EAR、WAR のような出力ファイルが build/libs
ディレクトリに作成されます。 upload-artifact
アクションを使用して、そのディレクトリの内容をアップロードできます。
steps:
- uses: actions/checkout@v3
- uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
- name: Build with Gradle
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: build
- uses: actions/upload-artifact@v3
with:
name: Package
path: build/libs