コンテンツにスキップ

Pull Request のレビュー状況を分析する

GitHub Actions 上で動くpull-request-analytics-actionを使い、Pull Request のレビュー時間とレビュー参加状況を可視化しました。ワークフローの設定例を示し、公式 README から辿れるサンプルレポートの読み方も解説します。

pull-request-analytics-action とは

以下は、公式 README にある機能説明を LLM で要約したものです。

この GitHub Action は、プルリクエストとコードレビューに関するメトリクスを計測し、レポートを issue として生成します。プルリクエストの作成・クローズ、レビューのリクエスト・実施、ディスカッション開始などのユーザーアクションに基づいて、コードレビュープロセスのボトルネック特定、トレンド追跡、重要な偏差検出、注目すべきプルリクエストの分析を支援します。

レポートには、プルリクエストのタイムライン、ワークロード、レビュー参加者視点からのディスカッションの活発さ、変更要求、コメント数、承認状況などが、表やグラフ、リストで表示されます。日付範囲、メトリクスの種類、グラフの種類、表示ユーザーなどをカスタマイズ可能です。出力形式は issue、markdown、JSON から選択できます。

主な機能は、レビュー段階の遅延箇所の特定、時間経過によるレビュー状況の変化分析、チームや開発者間のメトリクスの違いによる潜在的問題点の特定、重要なプルリクエストの分析簡素化です。 複数のリポジトリや組織からのデータ収集には、適切なスコープを持つ Personal Access Token の使用が推奨されます。

— pull-request-analytics-action README（LLM による要約）

つまり、PR の作成からレビュー、クローズまでの一連のアクションを追跡するアクションです。レビュー段階の遅延箇所やチーム間の差を、Issue 上のレポートとして可視化できます。

使い方

公式 README の設定例をもとにワークフローを作成し、GitHub Actions のworkflow_dispatchから手動実行します。設定例に登場する入力とパラメータの役割は次のとおりです。

項目 役割
report_date_start / report_date_end 手動実行時の入力。集計期間（d/MM/yyyy）を指定する
REPORT_DATE_START / REPORT_DATE_END 上の入力を受け取るパラメータ
GITHUB_TOKEN GitHub のトークン（必須）。Issues と Pull Requests の読み書き権限が要る
GITHUB_REPO_FOR_ISSUE / GITHUB_OWNER_FOR_ISSUE レポートを出力する Issue の作成先
GITHUB_OWNERS_REPOS 集計対象のリポジトリ
CORE_HOURS_START / CORE_HOURS_END コアタイムの開始・終了時刻（HH:mm）
TIMEZONE アクションで使うタイムゾーン（既定は UTC）

上表の設定を.github/workflows/配下のワークフローファイルに反映すると、次のようになります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
name: "PR Analytics"
on:
  workflow_dispatch:
    inputs:
      report_date_start:
        description: "Report date start(d/MM/yyyy)"
        required: false
      report_date_end:
        description: "Report date end(d/MM/yyyy)"
        required: false
jobs:
  create-report:
    name: "Create report"
    runs-on: ubuntu-latest
    steps:
      - name: "Run script for analytics"
        uses: AlexSim93/pull-request-analytics-action@master
        with:
          GITHUB_TOKEN: ${{ secrets.TOKEN }}
          GITHUB_REPO_FOR_ISSUE: "repo"
          GITHUB_OWNER_FOR_ISSUE: "owner"
          GITHUB_OWNERS_REPOS: "owner-1/repo-1"
          CORE_HOURS_START: "9:00"
          CORE_HOURS_END: "19:00"
          TIMEZONE: "Europe/Berlin"
          REPORT_DATE_START: ${{ inputs.report_date_start }}
          REPORT_DATE_END: ${{ inputs.report_date_end }}

例

ワークフローを実行すると、GITHUB_REPO_FOR_ISSUEとGITHUB_OWNER_FOR_ISSUEで指定したリポジトリの Issue にレポートが生成されます。以下は、公式 README の Report Examples から辿れるサンプル（Last N PRs Report）の抜粋です。

timeline の例

サンプルの集計対象は、更新日時が新しい Pull Request 50 件です。サンプルの数値だけでチーム全体の優劣を判断せず、レビューの滞留箇所を探す材料として、2023 年 12 月分の集計を読んでいきます。

Pull Request report

This report based on 50 last updated PRs. To learn more about the project and its configuration, please visit Pull request analytics action.

Below are the settings applied for this report:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
GITHUB_OWNERS_REPOS: owner/repo
GITHUB_OWNER_FOR_ISSUE: issue-owner
GITHUB_REPO_FOR_ISSUE: issue-repo
LABELS: Report
SHOW_STATS_TYPES: timeline, workload, pr-quality, code-review-engagement
TOP_LIST_AMOUNT: 3
AGGREGATE_VALUE_METHODS: percentile
PERCENTILE: 75
TIMEZONE: Europe/Berlin
CORE_HOURS_START: 10:00
CORE_HOURS_END: 19:00
AMOUNT: 50
PERIOD_SPLIT_UNIT: months
EXECUTION_OUTCOME: markdown

冒頭の設定ブロックのうち、レポートの読み方に関わるパラメータは次のとおりです。

パラメータ サンプルでの値 意味
GITHUB_OWNERS_REPOS owner/repo 集計対象のリポジトリ
GITHUB_OWNER_FOR_ISSUE / GITHUB_REPO_FOR_ISSUE issue-owner / issue-repo レポートを出力する Issue の作成先
SHOW_STATS_TYPES timeline, workload, pr-quality, code-review-engagement 集計する統計の種類
TOP_LIST_AMOUNT 3 longest-pending などのリストに表示する PR の件数
AGGREGATE_VALUE_METHODS / PERCENTILE percentile / 75 timeline の集計方法
PERIOD_SPLIT_UNIT months 集計期間を区切る単位

Pull requests timeline(percentile75) 12/2023

Time to review - time from PR creation to first review. Time to approve - time from PR creation to first approval without requested changes. Time to merge - time from PR creation to merge.

user Time to review Time to approve Time to merge Total merged PRs
dev1 3 hours 34 minutes 7 hours 32 minutes 14 hours 9 minutes 22
dev2 4 hours 4 hours 23 hours 1 minute 13
dev3 15 hours 16 minutes 24 hours 7 minutes 53 hours 43 minutes 2
dev4 2 hours 41 minutes 9 hours 15 minutes 47 hours 41 minutes 8
dev5 5 hours 59 minutes 18 hours 55 minutes 40 hours 7 minutes 2
total 4 hours 21 minutes 7 hours 36 minutes 26 hours 14 minutes 47 
gantt
title Pull requests timeline(percentile75) 12/2023 / minutes
dateFormat X
axisFormat %s
section dev1
                Time to review(3 hours 34 minutes) :  0, 214
Time to approve(7 hours 32 minutes) :  0, 452
Time to merge(14 hours 9 minutes) :  0, 849

section dev2
                Time to review(4 hours) :  0, 240
Time to approve(4 hours) :  0, 240
Time to merge(23 hours 1 minute) :  0, 1381

section dev3
                Time to review(15 hours 16 minutes) :  0, 916
Time to approve(24 hours 7 minutes) :  0, 1447
Time to merge(53 hours 43 minutes) :  0, 3223

section dev4
                Time to review(2 hours 41 minutes) :  0, 161
Time to approve(9 hours 15 minutes) :  0, 555
Time to merge(47 hours 41 minutes) :  0, 2861

section dev5
                Time to review(5 hours 59 minutes) :  0, 359
Time to approve(18 hours 55 minutes) :  0, 1135
Time to merge(40 hours 7 minutes) :  0, 2407

section total
                Time to review(4 hours 21 minutes) :  0, 261
Time to approve(7 hours 36 minutes) :  0, 456
Time to merge(26 hours 14 minutes) :  0, 1574

longest-pending reviews

  1. Feature: PR Title(example) (7 hours 26 minutes)
  2. Feature: PR Title(example) (7 hours 20 minutes)
  3. Feature: PR Title(example) (7 hours 10 minutes)

longest-pending approvals

  1. Feature: PR Title(example) (2 hours 15 minutes)
  2. Feature: PR Title(example) (2 hours 7 minutes)
  3. Feature: PR Title(example) (2 hours 3 minutes)

longest-pending merge

  1. Feature: PR Title(example) (2 hours 33 minutes)
  2. Feature: PR Title(example) (2 hours 30 minutes)
  3. Feature: PR Title(example) (2 hours 12 minutes)

workload の例

workload の表は、ユーザーごとの作業量の集計です。開いた PR 数やマージした PR 数に加えて、差分行数や PR サイズの内訳、コメント数、レビュー実施件数を並べています。2024 年 1 月時点の公式 README によれば、この表から個々の開発者とチーム全体の作業量をおおよそ測れます。

Workload stats 12/2023

Reviews conducted - number of reviews conducted. 1 PR may have only single review.

PR Size - determined using the formula: additions + deletions * 0.5. Based on this calculation: 0-50: xs, 51-200: s, 201-400: m, 401-700: l, 701+: xl

user Total opened PRs Total merged PRs Additions/Deletions PR size: xs/s/m/l/xl Total comments Reviews conducted
dev1 24 22 +1448/-3110 14/5/4/0/1 41 8
dev2 14 13 +813/-2062 7/4/1/2/0 6 20
dev3 2 2 +15/-3 2/0/0/0/0 1 10
dev4 8 8 +5416/-4600 6/0/1/0/1 7 9
dev5 2 2 +838/-362 1/0/0/0/1 16 2
total 50 47 +8530/-10137 30/9/6/2/3 71 46

quality の例

quality の表では、マージした PR が受けた反応を作成者の視点で集計しています。変更要求（changes requested）を受けた件数、ディスカッションでの合意・不合意の件数、受け取ったコメント数がわかります。2024 年 1 月時点の公式 README によれば、コードレビューで問題が多い箇所を特定し、その程度を数量化するのに役立つ表です。表の後には、コメント数の多い PR へのリンク（The most commented PRs）が続きます。

Pull request quality 12/2023

Agreed - discussions with at least 1 reaction 👍.

Disagreed - discussions with at least 1 reaction 👎.

user Total merged PRs Changes requested received Agreed / Disagreed / Total discussions received Comments received
dev1 22 3 0 / 0 / 10 20
dev2 13 1 0 / 0 / 2 3
dev3 2 0 0 / 0 / 1 1
dev4 8 1 0 / 0 / 4 4
dev5 2 1 3 / 2 / 8 9
total 47 6 3 / 2 / 25 37

The most commented PRs

  1. Feature: PR Title(example)(18)
  2. Feature: PR Title(example)(16)
  3. Feature: PR Title(example)(15)

code review engagement の例

code review engagement の表は、quality とは逆にレビューする側の視点で集計したものです。ユーザーごとに、レビューで始めたディスカッションの数やコメント数、レビューした PR のサイズ、変更要求・コメント・承認の件数がわかります。

Code review engagement 12/2023

PR Size - determined using the formula: additions + deletions * 0.5. Based on this calculation: 0-50: xs, 51-200: s, 201-400: m, 401-700: l, 701+: xl

Changes requested / Comments / Approvals - number of reviews conducted by user. For a single pull request, only one review of each status will be counted for a user.

Agreed - discussions with at least 1 reaction 👍.

Disagreed - discussions with at least 1 reaction 👎.

user Total merged PRs Agreed / Disagreed / Total discussions conducted Comments conducted PR size: xs/s/m/l/xl Changes requested / Commented / Approved
dev1 22 0 / 0 / 0 0 5/2/0/1/0 0 / 0 / 8
dev2 13 3 / 2 / 22 33 10/3/4/0/3 5 / 8 / 20
dev3 2 0 / 0 / 2 3 4/2/1/2/1 1 / 1 / 10
dev4 8 0 / 0 / 0 0 6/2/1/0/0 0 / 0 / 9
dev5 2 0 / 0 / 1 1 2/0/0/0/0 0 / 1 / 2
total 47 3 / 2 / 25 37 30/9/6/2/3 6 / 12 / 46

レポートの構成

レポートの構成は、大きく次の区分に分かれます。

区分 内容
timeline PR 作成からレビュー・承認・マージまでにかかった時間をユーザーごとに集計し、表とガントチャートで示す
workload・quality 開いた PR 数やコメント数、レビュー結果への合意・不合意といった作業量と反応を集計する
code review engagement 逆にレビューする側として何件対応し、どのサイズの PR にどう反応したかを示す
longest-pending 各リスト・most commented PRs それぞれの指標で滞留・反応が大きかった PR へのリンク集

サンプルでは、この 12/2023 単月の集計に続けて、集計期間全体（total）を対象にした同形式のセクションも載っています。表の見出しが「12/2023」から「total」に変わるだけで、行の意味や読み方は単月分と同じです。そのため、ここでは単月分の抜粋にとどめます。

まとめ

pull-request-analytics-action を使うと、公式 README の設定例どおりにワークフローを作成してworkflow_dispatchから手動実行するだけで、Pull Request のレビュー時間や参加状況を Issue 上のレポートとして可視化できます。GITHUB_OWNERS_REPOSなどの入力パラメータで集計対象を指定でき、出力する統計の種類や集計単位、percentile もカスタマイズできます。サンプルレポートを読むときは、timeline・workload・quality・code review engagement のどの観点の表かを意識してください。数値の優劣そのものよりも、レビューの滞留箇所を探す材料として扱うとよいです。