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

はじめに

このガイドは、Gradleビルドシステムを使ってJavaのプロジェクトのための継続的インテグレーション（CI）を実行するワークフローを作成する方法を紹介します。 作成するワークフローによって、プルリクエストに対するコミットがデフォルトブランチに対してビルドあるいはテストの失敗を引き起こしたことを見ることができるようになります。このアプローチは、コードが常に健全であることを保証するための役に立ちます。 CI ワークフローを拡張して、ワークフロー実行による成果物をアップロードできます。

必要なソフトウェアをセルフホステッド ランナーにインストールする必要があります。 セルフホステッド ランナーの詳細については、「自分のランナーをホストする」を参照してください。

前提条件

YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳細については、次を参照してください。

• 「ギットハブ　アクション　のワークフロー構文」
• GitHub Actions について

Java及びGradleフレームワークの基本的な理解をしておくことをおすすめします。 詳細については、「Gradle のユーザー マニュアル」を参照してください。

Gradle スターター ワークフローの使用

すぐに開始するには、リポジトリの .github/workflows ディレクトリにスターター ワークフローを追加します。

GitHub には、ほとんどの Gradleプロジェクトの Java で動作する Gradle のスターター ワークフローが用意されています。 このガイドの以降のセクションでは、このスターター ワークフローをカスタマイズする方法の例を示します。

1. ご自分のエンタープライズ で、リポジトリのメイン ページへ移動します。

2. リポジトリ名の下にある [アクション] をクリックします。

   

3. ワークフローが既にリポジトリ内にある場合は、 [新しいワークフロー] をクリックします。

4. 「ワークフローの選択」ページには、推奨されるスターター ワークフローの選択内容が表示されます。 「Java with Gradle」を検索します。

5. 「Java with Gradle」ワークフローで、[設定] をクリックします。

   「Java with Gradle」スターター ワークフローが見つからない場合は、次のワークフロー コードをリポジトリの .github/workflows ディレクトリで gradle.yml を呼び出した新しいファイルにコピーします。

   YAML

   name: Java CI with Gradle
   
   on:
     push:
       branches: [ "main" ]
     pull_request:
       branches: [ "main" ]
   
   permissions:
     contents: read
   
   jobs:
     build:
       runs-on: ubuntu-latest
   
       steps:
       - uses: actions/checkout@v4
       - name: Set up JDK 11
         uses: actions/setup-java@v3
         with:
           java-version: '11'
           distribution: 'temurin'
       - name: Build with Gradle
         uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
         with:
           arguments: build
   

6. 必要に応じてワークフローを編集します。 たとえば、Java のバージョンを変更します。

   注:

   • このスターター ワークフローでは、GitHub によって認定されていないアクションが使われます。 サード パーティによって提供されるアクションには、個別のサービス使用条件、プライバシー ポリシー、およびサポート ドキュメントが適用されます。
   • サード パーティのアクションを使用するには、コミット SHA で指定されたバージョンを使用する必要があります。 アクションが変更された新しいバージョンを使用する場合は、SHA を更新する必要があります。 タグまたはブランチを参照してバージョンを指定できますが、アクションは警告なしに変更される可能性があります。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。

7. [変更をコミットする] をクリックします。

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

スターター ワークフローで x64 プラットフォーム用の OpenJDK 8 を含むように PATH を設定します。 異なるバージョンの Java を使用する場合、あるいは異なるアーキテクチャ (x64 または x86) をターゲットとする場合、setup-java アクションを使って異なる Java ランタイム環境を選択できます。

たとえば、x64 プラットフォームに対して Adoptium によって提供される JDK のバージョン 11 を使用するには、setup-java アクションを使用して、java-version、distribution、architecture パラメーターを '11'、'temurin'、x64 に設定します。

steps:
  - uses: actions/checkout@v4
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'temurin'
      architecture: x64

steps:
  - uses: actions/checkout@v4
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'temurin'
      architecture: x64

詳細については、「setup-java アクション」を参照してください。

コードのビルドとテスト

ローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。

スターター ワークフローでは、既定で build タスクが実行されます。 デフォルトのGradleの設定では、このコマンドは依存関係をダウンロードし、クラスをビルドし、テストを実行し、たとえばJARファイルのような配布可能なフォーマットにクラスをパッケージします。

プロジェクトのビルドに異なるコマンドを使ったり、異なるタスクを使いたいのであれば、それらを指定できます。 たとえば、ci.gradle ファイルで構成されている package タスクを実行できます。

steps:
  - uses: actions/checkout@v4
  - 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

steps:
  - uses: actions/checkout@v4
  - 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

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

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

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

steps:
  - uses: actions/checkout@v4
  - 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

steps:
  - uses: actions/checkout@v4
  - 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