以前、Android プロジェクトへ ktlint を導入する手順をこちらに書きました。
⇒ ktlint の導入と感想
今回は、GitHub のプルリクエスト時に CI（Bitrise）上で ktlint によるコードスタイルのチェックをし、結果を Danger を利用してプルリクエストにレビューとして書き込む、というのを実現する設定を紹介したいと思います。
動作イメージ
なお、Danger 自体のセットアップについては長くなるので今回は説明しません。（また別の投稿で書こうと思っているので、もし書いたらリンクを追記します。）
[2019.01.16 追記] こちらに書きました -> Android の開発環境へ Danger を導入するメモ
Android プロジェクト側
ktlint の導入と感想 にも書きましたが、Gradle のタスクを次のようにしておきます。
task ktlint(type: JavaExec, group: "verification") {
description = "Check Kotlin code style."
classpath = configurations.ktlint
main = "com.github.shyiko.ktlint.Main"
args "--android", "--color", "--reporter=plain", "--reporter=checkstyle,output=${buildDir}/reports/ktlint-results.xml", "src/**/*.kt"
ignoreExitValue true
}
ポイントは CI（Bitrise） 用に checkstyle 形式での出力を追加しているのと、チェックにひっかかっても異常終了させない（ignoreExitValue true）ようにしているところです。（チェックにひっかかったらプルリクエストをマージさせたくない場合は ignoreExitValue false にすれば他の CI はどうか分かりませんが Bitrise ではスクリプトが失敗してマージできなくなります。）
このフラグで制御しなくても CI 上で異常終了をうまくハンドリングしたり、結果の XML を見て制御等できるかもしれませんが、ややこしくなり属人化の元になってしまうので、自分は CI 上で色々することは避けています。
Android プロジェクトのルートに置く Dangerfile は次のとおりです。
# 変更した行以外は指摘しないように
github.dismiss_out_of_range_messages
checkstyle_format.base_path = Dir.pwd
checkstyle_format.report "app/build/reports/ktlint-results.xml"
Bitrise 側
Danger を動かす最低限のワークフローは下図のとおりになるかと思います。
上図の赤枠のように、スクリプトに下記の記載をします。
# ...
./gradlew ktlint
gem install danger
gem install danger-checkstyle_format
danger
あとはこのワークフローを、GitHub のプルリクエストをトリガーにして起動するようにすればOKです。プルリクエストを送る度に、ktlint でチェックした結果がレビューとして書き込まれます。便利！
補足
今回、Danger や Danger プラグインの gem は Bundler で管理するようにしていませんが、Bundler で管理するようにしてもいいと思います。
おわりに
簡単にですが Bitrise、Danger を利用した、プルリクエストの自動レビューについて説明しました。Danger は今回はじめて触ってみたのですが、とても便利ですよね。個人的には機械でできるところは機械にやらせたいので、今後も便利な使い方を探っていきたいなと思っています。