ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
- GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
- アップグレード後のGitHub Actionsの設定に関する詳しい情報については、GitHub Enterprise Server 3.0のドキュメンテーションを参照してください。
ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。
はじめに
このガイドは、Gradleビルドシステムを使ってJavaのプロジェクトのための継続的インテグレーション(CI)を実行するワークフローを作成する方法を紹介します。 作成するワークフローによって、Pull Requestに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 CIワークフローを拡張して、ファイルをキャッシュし、ワークフローの実行による成果物をアップロードするようにもできます。
GitHubホストランナーは、Java Development Kits(JDKs)及びGradleを含むプリインストールされたソフトウェアを伴うツールキャッシュを持ちます。 JDK および Gradle のソフトウェアとプリインストールされたバージョンのリストについては、「GitHub でホストされているランナーの仕様」を参照してください。
必要な環境
YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳しい情報については、以下を参照してください。
Java及びGradleフレームワークの基本的な理解をしておくことをおすすめします。 詳しい情報については、GradleのドキュメンテーションのGetting Startedを参照してください。
GitHub Enterprise Server上でのセルフホストランナーの利用
GitHub Enterprise Server上でセルフホストランナーと合わせてセットアップアクション(actions/setup-LANGUAGE
のような)を使う場合、インターネットアクセスを持たないランナー上にツールキャッシュをセットアップする必要があるかもしれません。 詳しい情報については「インターネットアクセスを持たないセルフホストランナー上へのツールキャッシュのセットアップ」を参照してください。
Gradleワークフローテンプレートで始める
GitHubは、ほとんどのGradleベースのJavaプロジェクトで使えるGradleワークフローテンプレートを提供しています。 詳しい情報については、Gradle ワークフローテンプレートを参照してください。
素早く始めるには、新しいワークフローを作成する際に事前設定されたGradleテンプレートを選択できます。 詳しい情報については、「GitHub Actions のクイックスタート」を参照してください。
リポジトリの.github/workflows
に新しいファイルを作成して、手作業でこのワークフローを追加することもできます。
# このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# サポートドキュメンテーションが適用されます。
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
run: ./gradlew build
このワークフローは以下のステップを実行します。
checkout
ステップは、ランナーにリポジトリのコピーをダウンロードします。setup-java
ステップは、 Adoptium で Java 11 JDK を設定します。- The "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree.
- "Build with Gradle"ステップは、ラッパースクリプトの
gradlew
を実行し、コードがビルドされ、テストをパスし、パッケージが作成できることを保証します。
デフォルトのワークフローテンプレートは、ビルドとテストのワークフローを構築する際の素晴らしい出発点であり、プロジェクトの要求に合わせてこのテンプレートをカスタマイズできます。
様々なオペレーティングシステム上での実行
スターターワークフローテンプレートは、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
run: ./gradlew -b ci.gradle package
依存関係のキャッシング
GitHubホストランナーを使用する場合、依存関係をキャッシュしてワークフローの実行を高速化できます。 実行に成功した後、ローカルのGradleパッケージキャッシュがGitHub Actionsのインフラストラクチャ上に保存されます。 その後のワークフローの実行では、キャッシュがリストアされ、依存関係をリモートのパッケージリポジトリからダウンロードする必要がなくなります。 You can cache dependencies simply using the setup-java
action or can use cache
action for custom and more advanced configuration.
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
cache: gradle
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b
- name: Build with Gradle
run: ./gradlew build
- name: Cleanup Gradle Cache
# Remove some files from the Gradle cache, so they aren't cached by GitHub Actions.
# これらのファイルをGitHub Actionsのキャッシュからリストアすると、将来のビルドで問題が生じるかもしれない。
run: |
rm -f ~/.gradle/caches/modules-2/modules-2.lock
rm -f ~/.gradle/caches/modules-2/gc.properties
このワークフローは、ランナーのホームディレクトリ内の.gradle/caches
ディレクトリと.gradle/wrapper
ディレクトリにあるローカルのGradleパッケージキャッシュの内容を保存します。 キャッシュのキーはGradleのビルドファイル(Gradleのラッパー属性ファイルを含む)の内容のハッシュになるので、それらに変更があればキャッシュは無効になります。
成果物としてのワークフローのデータのパッケージ化
ビルドが成功し、テストがパスした後には、結果の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
- run: ./gradlew build
- uses: actions/upload-artifact@v2
with:
name: Package
path: build/libs