今、github actionsがコミットチャンスに溢れています！！
目的
開発しているサービスのリリースフローに一部手作業があるので、それを自動化したい…！
詳細
デプロイ
まず前提として、デプロイは特定のブランチへのプッシュをトリガーに、自動でデプロイされています。
| ブランチ | デプロイ先 |
|---|---|
| main | staging環境 |
| release | production環境 |
現状のリリースフロー
現状のリリースフローはこんな感じです。
- 作業ブランチで開発する。
- 作業ブランチからmainに向けてプルリクを出す。
- mainにマージされると、staging環境にデプロイされる。
- staging環境で動作確認をする。
- 誰かがmainからreleaseブランチに向けてプルリクを出す。mainとreleaseとの差分でコミットしている人全員をreviewerに入れる。
- reviewerが全員approveを出したら、マージする。
- releaseにマージされると、production環境にデプロイされる。
イマイチポイント
この辺りがイマイチポイントでした。
- 5番で手作業が発生する。
- mainからreleaseブランチに向けたプルリクを出すこと。
- 含まれているcommitのcommitterを探してreviewerに入れること。
- 6番で「全員からapproveもらったかな？」と思いきや、mainブランチにマージした新たなcommitterが現れて、またreviewしてもらわないといけない。
つくりたいもの
上記2点のイマイチポイントを改善するには、こんなものが作れると良さそうです。
- mainになにかがpushされたら、
- main -> releaseのプルリクが既にあるか探して、なければ作る。
- main -> releaseのプルリクのreviewerにpushした人を追加する。
バキバキにgithubの操作だし、未経験でしたが触ってみたかったので、github actionsを使うことにしました🙌
いざ開発！
github actionsはリポジトリにYAMLファイルを置くだけで動きます。早速動かしてみましょう！
クイックスタート: https://docs.github.com/en/free-pro-team@latest/actions/quickstart
github actionsのワークフローを開始するイベント
github actionsのワークフローを開始するイベントは3つに分かれます。
- スケジュールされたイベント
- 手動イベント
- webhookイベント: pushやpull-requestなど、githubにまつわるイベントが用意されています。
イベント詳細: https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows
私「おおお！mainブランチへのpushをトリガーにできる！まさに欲しかったものやないか！さすが…✨」
on:
push:
branches: [ main ]
Marketplaceという文化
github actionsは、JSやdockerを使ってゼロから自由に作ることができますが、作ったactionをMarketplaceに公開することで多くの人に利用してもらえます。
私「今回はゴリゴリの基本操作やから、全部Marketplaceで事足りるやろな〜」
Marketplaceでactionを探す
プルリクが検索ができるaction → あった！
私「まずはプルリク検索ができるactionを探すぞ👀」
私「あった！でもbaseブランチしか選べない…？そうなるとcompareブランチは制限できないのか…？（コードを見る）」
私「あ、READMEには書いてないけど指定できるみたいだ。ありがたや☺️」
プルリクがを作るaction → あった！
私「次はプルリクを作るactionを探すぞ〜！」
私「このactionは内部で古い文法を使ってるみたいでエラーが出るな」
私「お、こっちのactionはおっけーそう！ありがたや☺️」
プルリクにreviewerを追加するaction → なかった
私「次はプルリクにreviewerを追加するactionを探すぞ💪」
私「うーん、それらしいのはいっぱいあるんだけど、プルリクを引数で指定できなくて、プルリクオープンのtrigger限定でそのプルリクに追加するようなactionばっかりだなあ」
私「あれ？ないかも…？？」
>>> なかった <<<
私「なるほど、ほとんどのユースケースではプルリクをオープンするときにreviewerを設定していて、後から増やすようなことがないのか…」
私「コミットチャンス…！！作ろ！」
actionを作る
先にも述べましたが、github actionsはJSやdockerなどを使って作ることができます。
今回は軽量なactionなのでJSで作ることにしました。
こちらのドキュメントに作り方がとても丁寧に書かれていて、サッと作ることができました☺️☺️☺️
reviewerを追加するAPIを探す
ドキュメントにも書かれているように、githubの操作などは@actions/githubで定義されています。
@actions/githubに書かれている https://octokit.github.io/rest.js をからお目当てのメソッドを探します。
ありました！ちゃんとプルリクエストも指定できます☺️
https://octokit.github.io/rest.js/v18#pulls-request-reviewers
完成🎉
ドキュメントが丁寧で、あっという間に完成させることができました🙌
https://github.com/murs313/request-review
作ったactionをpublishする
actionを作ると、「publishせえへんか？」ってgithubが聞いてきます。
案内されるままにREADME.mdを整え、アイコンを付け、ポチッとすると…
＼＼＼わーーーーーい！！！／／／
公開したactionがMarketplaceに出てるー！🙌🙌🙌
まとめ
- ドキュメントが丁寧で、思っていたよりもずっと簡単にactionを作ることができました！
- 今回はいろんなactionを組み合わせてワークフローを作りましたが、パフォーマンス的にはまとめて作っちゃった方が良かったかも👀
- コミットチャンスがたくさんあるので、patchを送ったり新しいactionを作ったりして、誰かに使ってもらえたらハッピーですね☺️