まえがき
この記事はQiita GitHub Actions Advent Calendar 2019の14日目の記事です。(カレンダー作者なのに5日の大遅刻で申し訳ない)
GitHub Actions、みなさんどう思ってるんですかね。とりあえず新しいものが気になったので触ってみたら案外いい感じだったので私は個人プロジェクトならメイン採用しようと思っています。
それはさておき、ここではGradleを使ったプロジェクトでのGitHub Actionsの利用について書いていきます。
本文
動くサンプル
↑少し古いので、すでに解決したバグへの対処療法的なものが入っています
さて、GitHub ActionsでGradleの自動ビルド・テストに必要なのは主に以下の2つです。
- JDKのインストール
- 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を使っています)