Code Review в 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, такие как назначение, шепоты, уведомления, пользовательские рабочие процессы и многое другое. Каждый коммит в репозиторий становится темой. Ответы на тему отображаются на GitHub. Интеграция двусторонняя: вы можете комментировать в Discourse и видеть это на GitHub, или комментировать на GitHub и видеть это в Discourse.

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

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

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

Могу ли я увидеть это в действии?

Discourse поддерживает сайт https://review.discourse.org/, который является общедоступным, и любой может зарегистрироваться, используя учетные данные GitHub. На сайте показан только подмножество функций для нештатных пользователей. Более полный пример может выглядеть так:

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

Конфигурация

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

code review github webhook secret

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

URL полезной нагрузки: https://ВАШ_DISCOURSE/code-review/webhook
Тип содержимого: application/json
Секрет: значение code review github webhook secret
Типы событий:

  • Комментарии к коммитам
  • Комментарии к вопросам
  • Запросы на извлечение (pull requests)
  • Обзоры запросов на извлечение
  • Комментарии к обзорам запросов на извлечение
  • Пуши

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

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

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

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

code review pending tag: тег, применяемый ко всем nereцензированным коммитам, по умолчанию 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 skip duration minutes: нажатие кнопки пропуска на коммите предотвратит его повторное отображение в течение количества минут, установленного этой настройкой.

CHANGELOG

TODO

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

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

TL;DR — этот плагин разработан для дополнения использования GitHub командой Discourse для рецензирования кода.

Дополнительная информация

От @sam:

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

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

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

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

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

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

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

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

И список продолжается…

Таким образом, рецензирование служит дополнением к GitHub: мы используем GitHub для обработки изменений, которые еще не были приняты, а рецензирование — для правильного управления изменениями, которые уже были приняты.

71 лайк

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

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

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

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

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

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

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

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

1 лайк