从GitHub上提取评论

问题

我们公司针对评论进行了规定格式的规则设定。
作为设立规则的人，希望能对运营进行评估，但手动数据统计太麻烦了。

解决方案 (jiě jué àn)

由于GitHub提供了API，因此可以利用它。
https://docs.github.com/ja/rest
https://docs.github.com/ja/graphql

REST和GraphQL

我们有两种API可供选择，但这次我们选择了“GraphQL”格式。

原因

• GraphQLが実装されたAPIを触ってみたかったから

• APIの呼び出しが１つで、欲しいオブジェクト毎にエンドポイントが変わらない事

Enterprise版とドキュメントが共通っぽい（REST APIはドキュメントが違って苦労した）

让我们开发

因此，我们将制作一个抽取程序。

规格提取

• 団体”organization”を指定する

• リポジトリ”repository”を指定する

抽出期間（開始日～終了日）を指定する

筛选出1: 提取目标的拉取请求

由于目的是评估过去的情况，因此只提取已关闭且已合并的拉取请求。
在循环中使用do while，直到hasNextPage为FALSE时停止获取。

$pr_query_string = implode(' ', [
    "repo:{$org}/{$repo}",
    'is:pr',
    'is:closed',
    'is:merged',
    'merged:2023-05-08..2023-05-12',
    'sort:updated-desc',
]);

$request_string = <<< __EOF
{
    search(type:ISSUE, query: "{$pr_query_string}", first: 100, after: null) {
        issueCount
        pageInfo {
            hasNextPage
            endCursor
        }
        nodes {
          ... on PullRequest {
            number
            title
          }
        }
    }
}
__EOF;

请参阅下文

从给定的两个pull request中提取出评审中的内容。

基于提取的Pull Request编号，逐步执行查询以提取指定Pull Request的审查评论。由于我们公司的Pull Request策略是将其分割成较小的部分，因此审查数量和每个审查的线程都不会超过100个。不会超过吧？如果您计划创建超大的Pull Request导致数据溢出，那么我们可以从每个连接的pageInfo中获取游标，并适当实现分页。

$request_string = <<< __EOF
{
    repository(owner: "{$org}", name: "{$repo}") {
        pullRequest(number: {$pr_number}) {
            title
            reviews(first: 100) {
                totalCount
                nodes {
                    commit {
                        author {
                            name
                        }
                    }
                    comments(first: 100) {
                        totalCount
                        nodes {
                            body
                            author {
                                login
                            }
                        }
                    }
                }
            }
        }
    }
}
__EOF;

此外，请注意在GitHub API中一次请求所能获取的对象数量存在上限，请进行相应设计。

请参照以下内容进行翻译，仅提供一种选项：

参考

尝试使用GraphQL的感受。

考虑到长时间的抽取，虽然本次规模可能在一个请求中全部获取到，但我有一种感觉会超过对象上限，所以我将请求分为两个阶段。
使用REST API可以获取评审者的用户信息，但要获取到评审者（也就是提交评审的人）的用户信息，需要单独发送一个请求来获取个别提交信息的API。也就是说，需要根据评审评论的数量进行额外的请求。然而，使用GraphQL，我可以在一次查询中获取到所有信息，所以可以享受到GraphQL的优势的感觉。