補足したいイベント

issueで使うイベント

• issue：　ワークフローをトリガーするイベント (issues)\- GitHub Docs

  • assigneeが登録された / 外された
  • ラベルが追加された / 外された

  時にその時のissueのデータが欲しいので、

  • assigned
  • unassigned
  • labeled
  • unlabeled

  の時にレコード作成or更新させれば良さそう!

各イベント

PRで使えそうなイベント

• PR：ワークフローをトリガーするイベント (pull_request)\- GitHub Docs

  欲しいのは、そのユーザーがレビューを頼まれてるPRのデータなので、レビュワーとして登録された時&外された時(Approveしてレビューが終わった時)で十分そう。

  • review_requested
  • **review_request_removed ：これが具体的にどういう時かが肝!! これがApproveした時に当てはまらなければ、 pull_request_review というイベントも併用して使う必要がありそう。(ifで細かく条件指定できるので、何かしらレビューstate-APPROVED)**
  • closed ： reviewerがapproveしてない状態でマージされる(=closeになる)と、requested_reviewerに残ったままになってしまう。なので、statusを保存しておいて、 closed になったらアプリに表示させないようにする。表示させる時にstateがopenなものだけ表示させるようにしておいて、closedイベントが走ったら、stateをclosedにする処理をさせる)

pull_request_reviewイベント：ワークフローをトリガーするイベント \- GitHub Docs

プルリクエストレビューが送信(submitted)、編集(edited)、または却下(dismissed)されたときに、ワークフローを実行します。

プルリクエストレビューは、bodyコメントとstateに加えて、プルリクエストレビューコメントのグループです。プルリクエストレビューコメントまたはプルリクエストコメントに関連する活動については、代わりに pull_request_review_comment または issue_comment イベントを使用します。プルリクエストレビューAPIについては、GraphQL APIドキュメントの「PullRequestReview」またはREST APIドキュメントの「Pull request reviews」を参照してください。

(どういうイベントか予想)

• submitted ：review changesで submit review がクリックされた時

• edited ：レビューの内容が編集された時 → 一度submitすると、編集では approve などの変更はできない=レビュー状況は変化しないから、補足する必要はなさそう

  ↓ コメント内容の編集しかできなそう

  

• dismissed：人がレビューで change requested したものを却下( dismiss )できるので、その時を指すぽい。「人のレビューを却下する」

  • 本当はレビュー中だけど何らかの理由でその人がApproveできなくなった時に使うっぽい→レビューの途中でチーム開発を止める方は非常に稀 & 却下してるのは見たことがないので、first releaseでは補足しない。
  • プルリクエストレビューの却下 \- GitHub Docs

  

PRのイベントがいつ動くか、実際に試してみて記録

• pull_request
  • review_requested
    • reviewers に誰かが登録された
    • re-requested_review が押された
  • review_request_removed
    • reviewers から誰かが外された
    • ❌ レビュワーがreviewでcommentした
• pull_request_review
  • submit ： reviewがreview changesでsubmitされた時(↑の予想と同じ)

レビューの状況パターン洗い出しの表