Значение общего события c pull_request и других более специфических событий c pull_request, таких как pull_request.opened - PullRequest
Новая
       73

Значение общего события c pull_request и других более специфических событий c pull_request, таких как pull_request.opened

0 голосов
/ 10 апреля 2020

Я разрабатываю приложение GitHub с использованием nodejs и probot framework. Я вижу, что класс Application (https://probot.github.io/api/latest/classes/application.html) каркаса пробот содержит события вроде: 

> event: "pull_request" | "pull_request.assigned" |
> "pull_request.closed" | "pull_request.edited" | "pull_request.labeled"
> | "pull_request.opened" | "pull_request.reopened" |
> "pull_request.review_request_removed" |
> "pull_request.review_requested" | "pull_request.unassigned" |
> "pull_request.unlabeled" | "pull_request.synchronize

Я заметил, что когда " Нажата кнопка «Создать запрос на получение запроса» , затем запускаются события pull_request , а также pull_request.opened .

Чтобы понять это поведение запустив несколько, казалось бы, похожих событий при нажатии одной и той же кнопки , я попытался повторно открыть закрытый запрос и распечатать объект Context для события pull_request , а также pull_request.reopened событие.

Я провел сравнение обоих контекстов и обнаружил, что контексты, возвращаемые обоими событиями, идентичны, за исключением того, что контекст pull_request события содержится ниже дополнительные свойства: 

merged: false,
        mergeable: null,
        rebaseable: null,
        mergeable_state: 'unknown',
        merged_by: null,
        comments: 6,
        review_comments: 0,
        maintainer_can_modify: false,
        commits: 1,
        additions: 1,
        deletions: 0,
        changed_files: 1 },
     repository:
      { id: 123456789,
        node_id: '',
        name: '',
        full_name: '',
        private: true,
        owner: [Object],
        html_url: 'some-url-here'
        .
        .
        ///////////////////--------many more urls-------//////////////////////
        created_at: '2020-04-0',
        updated_at: '2020-04-0',

Мы знаем, что общий формат возвращаемого объекта контекста следующий: 

Context {
  name: 'pull_request',
  id: '187128937812-8219-89891892133-16752-1234576765545',
  payload:
   { action: 'reopened',
     number: 1,
     pull_request:
      { url:
        .
        .
        .and so on.......

Эта информация выше представлена ​​в b в других контекстах. Мы можем видеть, что это также говорит нам о конкретном c действии, которое было выполнено, и это обозначено context.payload.action . Таким образом, если кто-то хочет получить pull_request.opened , он / она может сделать это, просто используя событие pull_request следующим образом: 

app.on('pull_request', async context => {
    console.log('---------------------- on pull_request event')
    console.log('Context returned :----', context)
  })

И не нужно заботиться о других более специфических c событиях (здесь pull_request.opened ), т. Е. Помимо того, что достигается с помощью приведенного выше кода, приведенный ниже код не предоставит реальной дополнительной помощи: 

app.on('pull_request.opened', async context => {
    console.log('---------------------- on pull_request.opened')
    console.log('Context returned :----', context)
  })

Итак, вот вопрос, который меня беспокоит: какова цель события pull_request , если другие его конкретные формы c (например, pull_request.reopened ) ) не несут никакой другой информации (точнее, если их контексты не содержат никакой другой информации)?

Я совершенно уверен, что за этим стоит некоторая мудрость. Я не могу найти что-нибудь в inte rnet, ничего в документах, которые могли бы объяснить это.

Пожалуйста, помогите мне понять скрытую мудрость.

EDIT 1: START

Забыл упомянуть одно наблюдение, а именно: Повторное открытие запроса извлечения также вызывает событие issue_comment.created . Итак, три события запускаются одним действием (нажатие Создать запрос на извлечение ).

РЕДАКТИРОВАТЬ 2: СТАРТ

1 Ответ

1 голос
/ 11 апреля 2020

Какова цель события pull_request , если другие его конкретные формы c (например, pull_request.reopened ) не несут никакой другой информации (точнее, если их контексты не содержат никакой другой информации)?

Это просто особенность Probot для упрощения обработки событий webhook из GitHub. Я попытаюсь объяснить, почему это полезно.

Если бы вы использовали события webhook без Probot, вам пришлось бы анализировать каждое событие pull_request, проверить поле action для случая и решить,

Существует несколько событий с полем верхнего уровня action в полезной нагрузке, включая:

Вместо того, чтобы заставлять разработчиков приложений выполнять этот анализ и проверку самих JSON, они решили упростить обратные вызовы, чтобы вы могли подписаться на webhooks, используя заданный шаблон c [event].[action], и фреймворк позаботится о вызове обратного вызова при получении соответствующего события и действия.

Таким образом, у вас есть два варианта обработки событий pull_request:

  • , если вы не знаете, какие события вам нужны, или вам нужно динамически обрабатывать события, подпрограмма Подпись к pull_request - это то, как вы будете получать все события запроса на извлечение
  • , если вы знаете, какие события вы должны обрабатывать, и можете игнорировать остальные, подписка на явный pull_request.[event] должна упростить код вашего приложения

Вы также можете подписаться на *, который представляет все события, которые получает приложение-пробот, вместо явного перечисления всех поддерживаемых событий в вашем приложении.

...