突然ですが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