Получить все комментарии по всем вопросам с ярлыком

Question

Я пытаюсь заставить GitHub API предоставлять мне всю информацию, включая комментарии, по всем вопросам с определенной меткой.

Вот как я могу получить проблемы с этим ярлыком

curl -i https://api.github.com/repos/hadley/dplyr/issues?label=reprex/

Я могу получить комментарии по конкретной проблеме с

curl -i https://api.github.com/repos/hadley/dplyr/issues/2396/comments

Есть ли способ как-то совместить эти два вызова? Это, например, не работает

curl -i https://api.github.com/repos/hadley/dplyr/issues?label=reprex/comments

Answer 1

Для других, возможно, приехавших сюда годы спустя, таких как я (теперь, когда GraphQL доступен для GitHub), вот пример того, как я смог сделать что-то подобное для своих нужд сегодня (используя ваш вариант использования и примеры значений выше).

В GitHub GraphQL API Explorer (для которого вам может потребоваться дополнительно «войти» и согласиться, я думаю, чтобы измерить ограничения ресурсов), добавьте что-то вроде следующего кода запроса (и нажмите кнопку воспроизведения):

      {
  repository(name: "dplyr", owner: "hadley")
    issues(
      first: 100
      orderBy: {field: CREATED_AT, direction: ASC}
      filterBy: {labels: "reprex"}
    ) {
      edges {
        node {
          title
          url
          createdAt
          author {
            login
          }
          body
          comments(first: 100) {
            edges {
              node {
                createdAt
                author {
                  login
                }
                body
              }
            }
          }
        }
      }
    }
  }
}

Конечно замена dplyrс вашим репо, hadleyсо своим владельцем и reprexс вашей этикеткой.

Примечание 1 : orderByценности, а также такие вещи, как title/ url/ createdAt/etc также являются просто необязательными примерами элементов или параметров, которые мне нужны для возвращаемых данных (в дополнение к вопросу/комментарию bodys), но есть много других вариантов, которые потенциально можно использовать; переключение панели «Документы», кнопка «Проводник» или предложения рядом с курсором, где набор текста, казалось, был моим другом для открытия новых.

Примечание 2. Если вам нужны комментарии для запросов на вытягивание, замените их на pullRequests(или продублируйте весь большой блок под/в repository), но также обратите внимание, что многие «комментарии» в PR на самом деле являются «отзывами» под капотом, поэтому для моего варианта использования я просто сделал дополнительный блок reviewsдублирование того, что указано для comments, например:

                comments(first: 100) {
            ...
          }
          reviews(first: 100) {
            ...
          }

Примечание 3. Вы, по-видимому, ограничены 100 совпадениями за раз (хотя можете указать lastвместо first, или использовать другие параметры для дальнейшей фильтрации/сортировки), поэтому в тех случаях, когда у меня было/нужно было больше вопросов/PR для возврата, я дополнительно запрашивал pageInfoо них:

      {
  repository(name: "dplyr", owner: "hadley") {
    issues(
      first: 100
      orderBy: {field: CREATED_AT, direction: ASC}
      filterBy: {labels: "reprex"}
    ) {
      pageInfo {
        startCursor
        hasNextPage
        endCursor
      }
      edges {
       ...

Затем использовал строковое значение, которое было возвращено для endCursorдля afterаргумент issues. Например, если данные возвращены "endCursor": "a1b2c3", я бы повторно запустил запрос так:

      {
  repository(name: "dplyr", owner: "hadley") {
    issues(
      first: 100
      orderBy: {field: CREATED_AT, direction: ASC}
      filterBy: {labels: "reprex"}
      after: "a1b2c3"
    ) {
      edges {
       ...

чтобы получить следующую "страницу" результатов. То же самое, по-видимому, применимо к комментариям/отзывам, если у вас есть более 100 совпадающих комментариев/отзывов на узел.

Answer 2

Нет, я не видел способа объединить их только с GitHub API.

Объединение различных запросов в один обычно выполняется с помощью GraphQL (все еще в раннем доступе).

Мы поддерживаем GraphQL, потому что он предлагает гораздо больше гибкости для наших интеграторов.
Возможность точно определить и указать данные, которые вы хотите использовать для интеграции, является мощным преимуществом по сравнению с существующими конечными точками REST.