21
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

GitHubで自動更新のカンバン作ってみたい Pull requestイベント確認編

Last updated at Posted at 2017-06-20

はじめに

前回Pull requestイベントのWebhookを受信できるようにしました。
GitHubで自動更新のカンバン作ってみたい Webhook受信編 - Qiita
今回はPull requestイベントについて実際に何をするとどんなデータが送られてくるのか調べてみます。

この記事でやること

ラベル付け外しに限らずPull requestイベントは何に反応してどんなPOSTデータを送ってくるのか確認してまとめます。
情報は前回設定したWebhookからのデータを基にしています。

Pull requestイベントが反応するアクション

Pull requestでは以下の11アクションに反応してデータを送信します。
このリストにない―例えばプルリクにコメントした場合などは別のイベントです。

action 動作
opened プルリク作成
closed プルリクclose/ブランチマージ
reopened プルリク再open
edited タイトル・body編集/baseブランチ変更
assigned 担当追加
unassigned 担当除外
review requested レビューリクエスト
review requested removed レビューリクエスト取り下げ
labeled ラベル追加
unlabeled ラベル除外
synchronized ブランチにpushされたコミットをプルリクに反映

送信されるJSON

各種アクションで送信されるJSONを載せます。

共通構造

全アクション共通のデータ構造は次の通りです。
とあるOrganizationのリポジトリでやっているので、個人の場合はorganizationの部分が違います。 [未確認]
この記事ではアクションごとの特徴を取り上げたいと思います。
触れていない内容についてはEvent Types & Payloads | GitHub Developer Guideを参照してください。

共通構造
{
  "action": "アクション名",
  "number": プルリク番号,
  "pull_request": {
    "url": "プルリク取得APIのURL",
    "id": プルリクID,
    "html_url": "プルリクのURL",
    "diff_url": ".diffのURL",
    "patch_url": ".patchのUR",
    "issue_url": "issueAPIのURL",
    "number": プルリク番号,
    "state": "プルリクの状態(open/closed)",
    "locked": ロックされているかどうか,
    "title": "プルリクタイトル",
    "user": {プルリクを作った人の情報},
    "body": "プルリクのテキスト",
    "created_at": "プルリクを作成した日時",
    "updated_at": "プルリクを更新した日時",
    "closed_at": "プルリクをクローズした日時" 未クローズならnull,
    "merged_at": "プルリクをマージした日時" 未マージならnull,
    "merge_commit_sha": "マージコミットのsha" 未マージならnull,
    "assignee": {担当に設定している人の情報(先頭の1人)} 未設定ならnull,
    "assignees": [{担当に設定している人の情報(全員)}] [未設定なら空配列],
    "milestone": {設定したmilestone},
    "commits_url": "プルリクのコミット取得APIのURL",
    "review_comments_url": "プルリクのレビューコメント(全部)取得APIのURL",
    "review_comment_url": "プルリクのレビューコメント(単一)取得APIのURL",
    "comments_url": "プルリクのコメント(全部)取得APIのUrL",
    "statuses_url": "コミットのステータス取得APIのURL",
    "head": {マージ元ブランチの情報},
    "base": {マージ先ブランチの情報},
    "_links": {プルリク周りの各種URL},
    "requested_reviewers": [{レビューをリクエストされた人の情報}] [リクエストしていなければ空配列],
    "merged": マージしたかどうか,
    "mergeable": マージ可能かどうか openedアクションではnull,
    "rebaseable": リベース可能かどうか openedアクションではnull,
    "mergeable_state": "clean(マージ可能)" "unknown(openedアクションなど)" "その他不明",
    "merged_by": {マージした人の情報} マージしていなければnull,
    "comments": コメント数,
    "review_comments": レビューコメント数,
    "maintainer_can_modify": メンテナがプルリクを変更できるかどうか,
    "commits": コミット数,
    "additions": 追加・変更行数,
    "deletions": 削除行数,
    "changed_files": 追加・変更・削除ファイル数
  },
  "repository": {Webhookを設定したリポジトリの情報},
  "organization": {リポジトリが紐づいているOrganizationの情報},
  "sender": {アクションを実行したユーザーの情報}
}

pull_request.merge_commit_shaはややこしいので次のメジャーアップデート(2013-04-25の記事なのでv4のこと?)で削除するとのことです。
Deprecating a Confusing Attribute in the Pull Request API | GitHub Developer Guide

When you get the details for a Pull Request from the API, the response provides everything there is to know about that Pull Request. In addition to the useful information provided in the API response, the JSON also includes the merge_commit_sha attribute. This attribute is a frequent source of misunderstanding, and we aim to remove the confusion.

To help current API consumers, we've documented the attribute for improved understanding.

To protect future API consumers from this confusion, we have deprecated the merge_commit_sha attribute, and we will remove it in the next major version of the API.

プルリク作成

プルリク作成時の特徴
action = "opened"
pull_request.state = "open"
pull_request.mergeable = null
pull_request.rebaseable = null
pull_request.mergeable_state = "unknown"

プルリクclose

プルリクclose時の特徴
action = "closed"
pull_request.state = "closed"
pull_request.closed_at = "クローズした日時"
pull_request.merged_at = null
pull_request.merge_commit_sha = null
pull_request.merged = false
pull_request.mergeable = true
pull_request.rebaseable = false
pull_request.mergeable_state = "clean"
pull_request.merged_by = null

ブランチマージ

ブランチマージ時の特徴
action = "closed"
pull_request.state = "closed"
pull_request.closed_at = "マージした日時"
pull_request.merged_at = "マージした日時"
pull_request.merged = true
pull_request.mergeable = null
pull_request.rebaseable = null
pull_request.mergeable_state = "unknown"
pull_request.merged_by = {マージした人の情報}

プルリク再open

(データ収集できておらず)

プルリク再open時の特徴
action = "reopened"

タイトル編集

タイトル編集時の特徴
action = "edited"
pull_request.title = "編集後のタイトル"
changes = {
  title : {
    from : "編集前のタイトル"
  }
}

body編集

body編集時の特徴
action = "edited"
pull_request.body = "編集後のbody"
changes = {
  "body": {
    "from": "編集前のbody"
  }
}

baseブランチ変更

baseブランチ変更時の特徴
action = "edited"
pull_request.base = {変更後のbaseブランチの情報},
changes = {
  "base": {
    "ref": {
      "from": "変更前のbaseブランチ名"
    },
    "sha": {
      "from": "そのブランチのHEADのsha"
    }
  }
},

担当追加

複数同時追加それぞれに対してPOSTされる。

担当追加時の特徴
action = "assigned"
assignee = {追加した担当の情報}

担当除外

複数同時除外時それぞれに対してPOSTされる。

担当除外時の特徴
action = "unassigned"
assignee = {除外した担当の情報}

レビューリクエスト

複数同時リクエスト時それぞれに対してPOSTされる。

レビューリクエスト時の特徴
action = "review requested"
pull_request.requested_reviewers = [{レビューリクエストされた人の情報(要素追加)}]
requested_reviewer = {レビューリクエストされた人の情報}

レビューリクエスト取り下げ

複数同時取り下げ時それぞれに対してPOSTされる。

レビューリクエスト取り下げ時の特徴
action = "review requested removed"
requested_reviewer = {レビューリクエスト取り下げされた人の情報}

ラベル追加

複数同時追加時それぞれに対してPOSTされる。

ラベル追加時の特徴
action = "labeled"
label = {追加したラベルの情報}

ラベル除外

複数同時除外時それぞれに対してPOSTされる。

ラベル除外時の特徴
action = "unlabeled"
label = {除外したラベルの情報}

プルリクのブランチにpush

プルリクのブランチにpush時の特徴
action = "synchronized"
before = "push前のHEADのsha"
after = "push後のHEADのsha"

次回予告

情報不足もありますが、とりあえずラベルを付け外しするとどんな情報が送られてくるのかについては理解しました。
次はいよいよ、プルリク作られたらプロジェクトのカードを作成し、ラベルが変更されたらカードを移動するようにしたいと思います。

GitHubで自動更新のカンバン作ってみたい プルリクとプロジェクトのカードを連動させる編 - Qiita

21
14
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
21
14

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?