Обзор кода Discourse

:discourse2: Сводка Discourse Code Review позволяет просматривать коммиты GitHub прямо в Discourse.
:hammer_and_wrench: Ссылка на репозиторий https://github.com/discourse/discourse-code-review
:open_book: Руководство по установке Как установить плагины в Discourse

Возможности

Что это такое?

Плагин Discourse Code Review обеспечивает двустороннюю интеграцию с репозиториями кода GitHub. Он позволяет вашей команде просматривать коммиты в репозитории, используя возможности и плагины Discourse, такие как назначение задач, шепоты (whispers), уведомления, настраиваемые рабочие процессы и многое другое. Каждый коммит в репозитории становится темой. Ответы на тему дублируются на GitHub. Интеграция является двусторонней, что означает, что вы можете комментировать в Discourse и видеть это на GitHub, или комментировать на GitHub и видеть это в Discourse.

Он обеспечивает очень мощный рабочий процесс для команд, которым необходимо просматривать все коммиты в любом количестве репозиториев.

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

Примечание: При просмотре темы, которую можно одобрить, вы можете использовать кнопку y на клавиатуре, чтобы быстрее одобрять коммиты.

Можно ли увидеть это в действии?

Discourse использует этот плагин внутренне для отслеживания репозиториев. Пример стороны Discourse можно увидеть здесь:

На GitHub та же самая тема выглядит так:

Настройка

Плагин полагается на веб-хуки GitHub для обнаружения репозиториев и изменений в них. Для минимальной настройки вам необходимо установить следующее значение в виде секретной строки.

code review github webhook secret

После установки этого значения в вашем репозитории GitHub настройте веб-хук со следующими параметрами:

URL загрузки данных (Payload URL): https://YOUR_DISCOURSE/code-review/webhook
Тип содержимого (Content Type): application/json
Секрет (Secret): значение code review github webhook secret
Типы событий (Event Types):

  • Комментарии к коммитам
  • Комментарии к задачам
  • Pull requests
  • Ревью pull requests
  • Комментарии к ревью pull requests
  • Pushes

Плагин предоставляет следующие дополнительные настройки сайта:

code review api username : GitHub очень ограничивает количество разрешенных анонимных API-запросов. Эта настройка позволяет использовать учетные данные пользователя Discourse для запросов /comments и /commit. Это значительно снижает вероятность достижения лимитов запросов (rate limits).

code review catch up commits : количество коммитов, которые нужно «догнать» и для которых нужно создать темы при обнаружении нового репозитория.

code review default parent category: выберите категорию по умолчанию для категорий, создаваемых плагином.

code review pending tag: Тег, который применяется ко всем непроверенным коммитам, по умолчанию pending.

code review approved tag: Тег, который применяется к одобренным коммитам, по умолчанию approved.

code_review_followup_tag: Тег, который применяется к коммитам, требующим последующей работы, по умолчанию follow-up.

code review allow self approval: Разрешено ли персоналу одобрять собственные коммиты?

code review default mute new categories: Новые категории, созданные code review, по умолчанию отключены для пользователей.

code review skip duration minutes: Нажатие кнопки пропуска на коммите предотвратит его повторное отображение в течение количества минут, заданного в этой настройке.

CHANGELOG

TODO

Дополнительно

Как Discourse использует этот плагин

Кратко — этот плагин был разработан, чтобы дополнить использование GitHub командой Discourse для ревью кода.

Более подробная информация

От @sam:

  • Мы по-прежнему используем PR через пользовательский интерфейс GitHub и любим делать PR для множества изменений. Здесь ничего не изменилось. GitHub — это здорово, мы любим GitHub. У них отличный рабочий процесс для изменений, которые еще не были приняты. Однако…

  • Рабочий процесс GitHub для изменений, которые были закоммичены напрямую в репозиторий, ужасен.

  • Review заполняет пробел, который просто невозможно заполнить с помощью GitHub сегодня. Мы хотим, чтобы хотя бы один член команды просматривал каждое изменение, внесенное в наши различные git-репозитории, принадлежащие Discourse. Если бы мы использовали пользовательский интерфейс, предоставляемый GitHub, никто никогда не смог бы делать ничего, кроме pull requests. Это значительно замедлило бы нас.

  • Нам нужна возможность общаться конфиденциально, не давая знать об этом всему миру, в отношении определенных изменений. Например: Нам лучше как можно скорее развернуть этот отличный фикс для `<вставьте название крупной компании>, @sam, ты можешь этим заняться*?

  • Нам нужна возможность одобрять внесенные изменения или запрашивать последующую работу, чего пользовательский интерфейс GitHub не предлагает.

  • Нам нужна возможность назначать определенные коммиты пользователю. Допустим, @sam делает коммит содержащий некоторые ошибки. Хорошо, что мы можем напрямую назначить ему этот конкретный коммит, пометить его для последующей работы и затем отслеживать, была ли эта работа выполнена.

  • Discourse довольно хорош во всем этом разговоре, и небольшие функции делают довольно большую разницу. Я могу видеть, когда люди печатают. Мне никогда не нужно обновлять страницы, чтобы изменения появились. Цитирование очень удобно, загрузка изображений тоже, и так далее.

  • Discourse действительно хорош в отслеживании прочитанного: вы получаете очень сильные гарантии того, что прочитали каждую вещь один раз. С GitHub я не имею понятия, какие коммиты я прочитал, а какие нет. У нас есть невероятно эффективный способ справиться с потоком информации.

И список можно продолжать…

Таким образом, review выступает как дополнение к GitHub: в настоящее время мы используем GitHub, чтобы справляться с изменениями, которые еще не были приняты. И мы используем review, чтобы правильно обрабатывать изменения, которые уже были приняты.

72 лайка

Я пытаюсь понять цель этого плагина. У меня есть предположение, что мне что-то подобное нужно, но я не вижу, как это повышает эффективность. Когда кто-то одобряет pull request и сливает его в ветку, что именно в вашем процессе требует ещё одного одобрения для связанного коммита?

GitHub не предлагает этого в отношении коммитов, поскольку предполагается, что это уже было решено в рамках pull request. Что я упускаю?

Возможно, дело в том, что в вашей команде есть люди, которые могут одобрять pull request, но не имеют квалификации для принятия окончательного решения по коммиту в контексте реального релиза? Цель ли это в том, чтобы pull request можно было быстро слить и проверить, не дожидаясь человека, имеющего последнее слово, с уверенностью, что этот человек или команда проверят коммит перед созданием релиза?

Или же это в первую очередь для поддержки приватных обсуждений в публичных репозиториях?

Мне бы очень хотелось получить более глубокое понимание преимуществ использования этого плагина в вашем рабочем процессе. Спасибо!

Это было в основном пережитком более ранних рабочих процессов в Discourse.

В те времена мы использовали его для ретроспективного утверждения наборов изменений.

Сейчас всё проходит через каналы PR, поэтому мы не так часто используем этот плагин.

1 лайк