【问题标题】:Using GitHub's GraphQL API, how can I tell who closed an issue or pull request?使用 GitHub 的 GraphQL API,我如何知道谁关闭了问题或拉取请求?
【发布时间】:2018-03-17 02:48:34
【问题描述】:

给定一个问题或拉取请求编号,我想通过对GitHub GraphQL API 的单个查询来获取以下信息:

  • 无论是问题还是拉取请求
  • 问题的状态(打开、关闭)或 PR(打开、关闭、合并)
  • 如果问题或 PR 已关闭,由谁关闭以及何时关闭
  • 如果问题或 PR 被合并,谁合并了,何时合并

使用以下查询,除了确定关闭了问题或 PR:

{
  repository(owner: "Automattic", name: "wp-calypso") {
    issueOrPullRequest(number: 23226) {
      __typename
      ... on Closable {
        closed
        closedAt
        # TODO: How to get ClosedEvent { actor } ?
      }
      ... on Issue {
        issueState: state
        title
      }
      ... on PullRequest {
        prState: state
        title
        merged
        mergedAt
        mergeCommit {
          committer {
            user {
              login
            }
          }
        }
      }
    }
  }
}

我正在使用 GitHub 的 GraphQL Explorer 工具运行此查询:https://developer.github.com/v4/explorer/

我可以将问题或 PR 视为 Closable,但我认为我需要从那里到达影响该对象的最后一个 ClosedEvent。这是我还没有弄清楚的部分。

在 GitHub 的 v3 REST API 中,确定所有这些信息可能需要 2 个请求。对于已关闭(未合并)的拉取请求,closed_by 字段仅在请求拉取请求作为问题时出现(通过issues API 调用)。所有其他拉取请求信息都可以通过pulls API 调用获得。

【问题讨论】:

    标签: graphql github-api


    【解决方案1】:

    获取关闭问题的演员的一种迂回(且丑陋)的方式如下(受此answer 启发)。我希望可能有更好的方法,但目前有一种方法。

    诀窍是查询给定时间线中的大量事件(如果您绝对确定问题/PR 关闭后没有 cmets,您可以说 timeline(last: 1)),找到 @其中987654323@或MergedEvent提取actor

    {
      repository(owner: "Automattic", name: "wp-calypso") {
        issueOrPullRequest(number: 23226) {
          __typename
          ... on Closable {
            closed
            closedAt
          }
          ... on Issue {
            timeline(last: 100) {
              edges {
                node {
                  __typename
                  ... on ClosedEvent {
                    actor{
                      login
                    }
                  }
                }
              }
            }
          }
          ... on PullRequest {
            timeline(last: 100) {
              edges {
                node {
                  __typename
                  ... on MergedEvent {
                    actor{
                      login
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
    

    【讨论】:

    • 感谢指向timeline 字段的指针,我认为这是我在这里缺少的连接。但是,建议的查询最终会非常冗长,以涵盖最常见的可能性,并且在某些情况下仍然会失败(如果问题或 PR 在关闭或合并后有许多 cmets 或其他事件)。操作此响应对象所需的代码也比仅向 REST API 发出 2 个请求要复杂得多。我接受这个解决方案是正确的,但我认为总体答案是“使用 GraphQL API 无法完成此任务”。
    • @jnylen 我同意。有一个简洁的方法来完成这件事会很好。另外,关于要解析的代码点很复杂,它仍然不会比通过网络调用 2 便宜吗?我没有对此进行基准测试,所以我不确定,不过只是一个值得深思的食物
    • 权衡... 1 个网络请求,在服务器端具有非常复杂的查询和未知的复杂性,这并不总是有效,并且需要客户端进行复杂的处理(难以测试)。或者,针对标准对象的 2 个相对简单的网络请求,之后再进行一些组合。
    • 我选择了 2 个请求(在我的应用程序中有适当的缓存)。这种方式更简单,更易于维护。
    • 说实话,我对这两种 GitHub API 的行为有点失望。
    猜你喜欢
    • 2023-04-02
    • 2017-10-24
    • 2015-04-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-17
    • 2012-08-27
    • 1970-01-01
    相关资源
    最近更新 更多