Skip to main content
ドキュメントには� �繁に更新が� えられ、その都度公開されています。本ページの翻訳はま� 未完成な部分があることをご了承く� さい。最新の情� �については、英語のドキュメンテーションをご参照く� さい。本ページの翻訳に問題がある� �合はこちらまでご連絡く� さい。

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

GradleでのJavaのビルドとテスト

GitHub Actions中で継続的インテグレーション(CI)ワークフローを作成し、GradleでJavaのプロジェクトのビルドとテストを行うことができます。

ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情� �を見ることができます。

はじめに

このガイドは、Gradleビルドシステ� を使ってJavaのプロジェクトのための継続的インテグレーション(CI)を実行するワークフローを作成する方法を紹介します。 作成するワークフローによって、Pull Requestに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 You can extend your CI workflow to upload artifacts from a workflow run.

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のような)を使う� �合、インターネットアクセスを持たないランナー上にツールキャッシュをセットアップする必要があるかもしれません。 詳しい情� �については「インターネットアクセスを持たないセルフホストランナー上へのツールキャッシュのセットアップ」を参照してく� さい。

Using the Gradle starter workflow

GitHub provides a Gradle starter workflow that will work for most Gradle-based Java projects. For more information, see the Gradle starter workflow.

To get started quickly, you can choose the preconfigured Gradle starter workflow when you create a new workflow. 詳しい情� �については、「GitHub Actions のクイックスタート」を参照してく� さい。

リポジトリの.github/workflowsに新しいファイルを作成して、手作業でこのワークフローを追� することもできます。

YAML
# このワークフローは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 uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee with: arguments: build

このワークフローは以下のステップを実行します。

  1. checkoutステップは、ランナーにリポジトリのコピーをダウンロードします。
  2. setup-java ステップは、 Adoptium で Java 11 JDK を設定します。
  3. The "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree.
  4. The "Build with Gradle" step does a build using the gradle/gradle-build-action action provided by the Gradle organization on GitHub. The action takes care of invoking Gradle, collecting results, and caching state between jobs. For more information see gradle/gradle-build-action.

The default starter workflows are excellent starting points when creating your build and test workflow, and you can customize the starter workflow to suit your project’s needs.

様々なオペレーティングシステ� 上での実行

The starter workflow configures jobs to run on Linux, using the GitHub-hosted ubuntu-latest runners. runs-onキーを変更し、異なるオペレーティングシステ� でジョブを実行するようにすることができます。 たとえば、GitHubホストのWindowsランナーを使うことができます。

runs-on: windows-latest 

あるいはGitHubホストのmacOSランナーで実行させることもできます。

runs-on: macos-latest 

Dockerコンテナ上でジョブを実行させたり、独自のインフラストラクチャ上で動作するセルフホストランナーを提供したりすることもできます。 詳細については、「GitHub Actionsのワークフロー構文」を参照してく� さい。

JVMのバージョンとアーキテクチャの指定

The starter workflow sets up the PATH to contain OpenJDK 8 for the x64 platform. 異なるバージョンのJavaを使いたい� �合、あるいは異なるアーキテクチャ(x64あるいはx86)をターゲットとしたい� �合には、setup-javaアクションを使って異なるJavaランタイ� 環境を選択できます。

たとえば、x64プラットフォー� 上でAdoptiumが提供するJDKのバージョン11を使うには、setup-javaアクションを使ってjava-versiondistributionarchitecture パラメータを'11''adopt'x64に設定できます。

YAML
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タスクを実行したいこともあるでしょう。

YAML
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@0d13054264b0bb894ded474f08ebb30921341cee with: arguments: -b ci.gradle package

成果物としてのワークフローのデータのパッケージ化

ビルドが成功し、テストがパスした後には、結果のJavaのパッケージをビルドの成果物としてアップロードすることになるかもしれません。 そうすれば、ビルドされたパッケージをワークフローの実行の一部として保存することになり、それらをダウンロードできるようになります。 成果物によって、Pull Requestをマージする前にローカルの環境でテスト及びデバッグしやすくなります。 詳しい情� �については「成果物を利用してワークフローのデータを永続化する」を参照してく� さい。

Gradleは通常、JAR、EAR、WARのような出力ファイルをbuild/libsディレクトリに作成します。 このディレクトリの内容はupload-artifactアクションを使ってアップロードできます。

YAML
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@0d13054264b0bb894ded474f08ebb30921341cee with: arguments: build - uses: actions/upload-artifact@v2 with: name: Package path: build/libs