利用する coustom action
次の action を利用します。
ワークフロー
上記 action を組み込んだワークフローは次のとおりです。
name: JUnit Test
on: pull_request
jobs:
test:
runs-on: ubuntu-latest
permissions:
contents: read # for checkout
checks: write # for dorny/test-reporter checks
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
with:
distribution: 'zulu'
java-version: 17
- run: ./gradlew test --continue
- if: cancelled() != true
uses: dorny/test-reporter@v1
with:
name: 'JUnit Test Report' # checks 名となる
path: '**/build/test-results/*/TEST-*.xml'
reporter: 'java-junit'
fail-on-error: false # test の step で既に job は fail になってるので
path では全モジュールのレポートを拾うようにしています。この例だとバリアントを指定せずテストを実行していますが、状況に応じてテストするバリアントを絞ってもよいと思います。
Gradle の --continue オプションにより、あるバリアントやモジュールで失敗するテストケースがあっても、レポートの為に最後まで継続するようにしています。最後まで継続しても、終了コードは 0 以外となる為、この step および job のステータスは fail となり CI は正しく？落ちてくれます。
この action の README のワークフローの例では actions: read permission も定義しているようですが、恐らく README で紹介されている workflow_run トリガーのワークフローを利用しない限り不要なんだと思います。
プルリクの Checks タブでは次のように表示されます。
また、プルリクの Files changed タブでは、失敗するテストケースがある場合は次のように表示されます。
GitHub の annotation の機能が利用されています（具体的には Checks API。ワークフローコマンド による annotation と見た目は一緒ですが、この action で利用しているのは Checks API の方で、ワークフローコマンドと比べて annotation の数の制限が緩和されているようです）。
通常、プルリクでレビューコメントできるのは、変更されたファイル且つ diff に含まれる範囲のみに限定されますが、テストに失敗するのはテストコード自体でなくテストコードの対象のコードの変更によるものです。GitHub の annotation の機能であればプルリクのレビューコメントと異なり、プルリクで変更したコードでなくてもここに表示することが出来るので、どのテストコードが落ちたのかプルリク作成者本人にもレビュアにも分かりやすくなります。
ほかの類似の action について
action-junit-report
こちらの action でもほぼほぼ問題はないのですが、テストクラス名とファイル名が一致していないと、パスが解釈されず正しく annotation がつかないので辞めました（揃えるべき論は別にして）。あと前項のワークフローで利用している action は、バリアント違いのテストを実行した際に、同じ行への annotation をひとつにまとめてくれていました。また全体的に、前項の action の方がシンプルで理解しやすいと思いました。
GitHub Action to Publish Test Results
仮にテストクラス名とファイル名が一致していたとしても、パスが解釈されず正しく annotation がつかないので採用は見送りました。
Discussion