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

Question

Я разрабатываю приложение GitHub, используя nodejs и платформу probot. Я вижу, что класс приложения (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.......

Приведенная выше информация присутствует в обоих контекстах. Мы можем видеть, что это также говорит нам о конкретном действии, которое было выполнено, и это обозначено 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)
  })

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

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

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

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

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

РЕДАКТИРОВАТЬ 1: НАЧАТЬ

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

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

Answer 1

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

Это всего лишь функция Probot для упрощения обработки событий веб-перехватчиков из GitHub. Я постараюсь объяснить, почему это полезно.

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

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

• check_run
• issue
• project
• pull_request
• и многое другое в документации...

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

Итак, у вас есть два варианта обработки pull_request События:

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

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