リリースフローを自動化していたら、github actionsをMarketplaceにpublishしていました。

今、github actionsがコミットチャンスに溢れています！！

目的

開発しているサービスのリリースフローに一部手作業があるので、それを自動化したい…！

詳細

デプロイ

まず前提として、デプロイは特定のブランチへのプッシュをトリガーに、自動でデプロイされています。

ブランチ	デプロイ先
main	staging環境
release	production環境

現状のリリースフロー

現状のリリースフローはこんな感じです。

1. 作業ブランチで開発する。
2. 作業ブランチからmainに向けてプルリクを出す。
3. mainにマージされると、staging環境にデプロイされる。
4. staging環境で動作確認をする。
5. 誰かがmainからreleaseブランチに向けてプルリクを出す。mainとreleaseとの差分でコミットしている人全員をreviewerに入れる。
6. reviewerが全員approveを出したら、マージする。
7. releaseにマージされると、production環境にデプロイされる。

イマイチポイント

この辺りがイマイチポイントでした。

• 5番で手作業が発生する。
  • mainからreleaseブランチに向けたプルリクを出すこと。
  • 含まれているcommitのcommitterを探してreviewerに入れること。
• 6番で「全員からapproveもらったかな？」と思いきや、mainブランチにマージした新たなcommitterが現れて、またreviewしてもらわないといけない。

つくりたいもの

上記2点のイマイチポイントを改善するには、こんなものが作れると良さそうです。

1. mainになにかがpushされたら、
2. main -> releaseのプルリクが既にあるか探して、なければ作る。
3. 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つに分かれます。

1. スケジュールされたイベント
2. 手動イベント
3. webhookイベント: pushやpull-requestなど、githubにまつわるイベントが用意されています。

イベント詳細: https://docs.github.com/ja/free-pro-team@latest/actions/reference/events-that-trigger-workflows

私「おおお！mainブランチへのpushをトリガーにできる！まさに欲しかったものやないか！さすが…✨」

'.github/workflows/hoge.yml'

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を作ったりして、誰かに使ってもらえたらハッピーですね☺️