突然ですがJavaのコード、なにで書いてますか？

私見ですが、ショートカットキーが手に馴染んだIDEとそうでないIDEでは明らかに作業効率が変わる気がします。
「IDEが選べる」「PCが選べる」はエンジニア採用の現場でも売りとして扱われているようですし、実際選べない会社より選べる会社の方が嬉しい。
ただ、実際選べる環境に入ってみると、それはそれでこんな状況が起こりがち。

Eclipseで書かれたコードをIntelliJ愛用者が編集（逆もまたしかり）
手癖でフォーマッタをかける
コードの差分が大変なことになる
レビューつらみ

フォーマッタはできれば統一したいところ。
一方で「ソースコードプッシュするときは、ビルドツールでフォーマットしてからにしましょう」とかルール化するのもそれはそれで面倒。
pre-commitのセッティングを各人にお願いしてもいいのですが、GitHub使ってるならそっちで勝手にやってくれれば楽なはず！

というわけで、設定してみました。
ビルドツールやフォーマッタはプロジェクトによって色々かとは思いますが、本記事ではGradle+Google Java Formatを扱います。

結論

google-java-format-gradle-pluginを導入
https://github.com/sherter/google-java-format-gradle-plugin
GitHub Actionsのworkflowを設定
https://github.com/tom-myz/shelffy/blob/master/.github/workflows/gradle.yml
アクセストークンを発行してリポジトリのシークレットに登録

これでフォーマッタバラバラでレビューしづらい問題とはおさらばできるかも！

気をつけるべきポイント

追加commitはコマンドで

実行結果をcommitする、みたいな機能は見つかりませんでした。
まじめにgitコマンドを書くほかなさそうです。

gitの参照先がデフォルトブランチになる

トリガーがpull_requestなのだからマージ元のブランチをローカルに複製して参照してくれてる
……なんてことはなく、ブランチのcheckoutを抜かすとHEADにコミットされます。
originは設定されているようです。

continue-on-errorを設定したstepは終了コードに関わらずsuccessする

後続のstepにif success()をおいても意味が無くなります。
コマンドAが失敗した場合、コマンドBをスキップしてコマンドC以降を実行とかやりたい場合、

コマンドA・コマンドBを同一ステップにおいてcontinue-on-error
コマンドC以下は次のステップに配置

で実現するのがよさそうです。

その他

何か思い出したら追記するかもしれません。しないかもしれません。

イケてない点

歴史あるリポジトリだと適用した瞬間の差分が大変なことになる
→ それ以前まで遡ろうとすると結局git blameしづらい問題
ユーザー名とメールアドレスが具体的すぎる
→ 実プロジェクトでやるなら専用ユーザー用意した方がいいとおもいます
フォーマッタかけたあとのコミットにももう一度フォーマッタをかけようとする
→ しかも結構時間がかかる。JDKのインストールからやってることもあり、内容Hello worldレベルでも1分半ほど
コミット数が純増してログがきたない
→ squashとかで行けそうな気もしつつ、Gitちからが足りなすぎてモチベーションがつづかなかった

感想

GitHub Actionsはよいものでしたが、肝心のGitの知識がなさすぎてやたらと時間かかりました。
仁義なきコスメティック・レビューから一人でも多くの開発者が解放されますように！

参考文献

https://help.github.com/ja/actions
http://nomadblacky.hatenablog.com/entry/2018/10/27/145451