GitHub ActionsでGradleの自動ビルド/テストをする [再掲]

Qiita→Qrunch移行のためのQiita版の自己転載です。

まえがき

この記事はQiita GitHub Actions Advent Calendar 2019の14日目の記事です。(カレンダー作者なのに5日の大遅刻で申し訳ない)

GitHub Actions、みなさんどう思ってるんですかね。とりあえず新しいものが気になったので触ってみたら案外いい感じだったので私は個人プロジェクトならメイン採用しようと思っています。

それはさておき、ここではGradleを使ったプロジェクトでのGitHub Actionsの利用について書いていきます。

本文

動くサンプル
↑少し古いので、すでに解決したバグへの対処療法的なものが入っています

さて、GitHub ActionsでGradleの自動ビルド・テストに必要なのは主に以下の2つです。

  1. JDKのインストール
  2. Gradleタスクの実行

それぞれ見ていきましょう

JDKのインストール

これはActionが存在します。actions/setup-javaです。このActionを使えば一発でJDKをインストールしてくれます。

- name: "Setup Java"  
  uses: actions/setup-java@v1  
  with:  
    java-version: 11  

この様な感じでjava-versionで指定したバージョンのJDKをインストールする事ができます。詳細は公式のREADME.mdを見てください。

Gradleのタスクの実行

gradlew testを実行するくらいならコマンドを手打ちしてもいいのですが、複雑な設定をするとなると少し面倒です。そこで登場するのがeskatos/gradle-command-actionというAction。
Gradleコマンドをラップしていい感じに処理してくれます。便利。
テストコマンドの実行は以下のようにできます。


- name: run test  
  uses: eskatos/gradle-command-action@v1  
  with:  
    arguments: test  

環境変数を渡す場合は以下のような感じ

- name: run test  
  uses: eskatos/gradle-command-action@v1  
  with:  
    arguments: test  
  env:  
    ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}  

envセクションにkey-valueでかけます。
他の細かい機能はREADME.mdを見てください。

完成形

キャッシュとかの処理もするとこんな感じになります


name: Run Gradle on PRs and Pushes  
on: [pull_request, push]  

jobs:  
  test:  
    strategy:  
      matrix:  
        os: [ubuntu-latest, macos-latest, windows-latest]  
    runs-on: ${{ matrix.os }}  

    steps:  
      - uses: actions/checkout@v1  

      - name: "Cache ~/.gradle/caches"  
        uses: actions/cache@preview  
        with:  
          path: "~/.gradle/caches"  
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/build.gradle.kts') }}  
          restore-keys: ${{ runner.os }}-gradle-  

      - name: "Setup Java"  
        uses: actions/setup-java@v1  
        with:  
          java-version: 11  

      - name: run test  
        uses: eskatos/gradle-command-action@v1  
        with:  
          arguments: test  
        env:  
          ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}  

      - name: Upload artifact  
        uses: actions/upload-artifact@v1.0.0  
        with:  
          name: test-result-${{ matrix.os }}  
          path: build/reports/tests  

ちなみにGradleのキャッシュは~/.gradleディレクトリを丸々指定するとGradle WrapperによってダウンロードされたGradleのファイルもキャッシュされるんですが、GitHub Actionsのキャッシュの容量上限的にライブラリのキャッシュとWrapperのキャッシュのどちらか一方しか入らない現状です。(それでも以前のどちらも入り切らない状況よりはマシですが)
なのでここではライブラリのキャッシュ(~/.gradle/caches)に絞っています。キャッシュ上限に引っかからないためにも、依存ライブラリのバージョンが上がるたびにキャッシュがリセットされるように、キャッシュのkeyに用いているhashFiles()の中に依存ライブラリのバージョンを記述しているファイルをすべて入れておいたほうがいいでしょう。

最後に

ほぼほぼ「使える既存のActionを紹介する」だけの記事になりましたがどうでしょうか。価値あるんですかね。
最後のキャッシュに関する戦略についても、私はまだ初心者なので強い人いたら教えてもらえるとありがたいですね。

ところでこの記事を読んでいる人にはあまり関係はなさそうですが、私のバイト先の会社がフロントエンドエンジニアの募集に力を入れているみたいなので興味のある方はどうぞ(当然アプリ/バックエンドのエンジニアの募集もあります)(弊社はCircle CIを使っています)