Общаться с Control Center из GitHub PR
В этом руководстве показано, как работать с Control Center, не покидая GitHub: запросить ИИ-проверку со страницы PR, задать боту вопрос в комментарии и продолжить разговор в его ветках ревью.
Бот — это собственный GitHub App вашего сервера, тот же самый, который уже выполняет вход пользователей и фоновую работу. Ничего нового не регистрируется, и ничто не должно быть доступно из интернета: сервер узнаёт о сказанном на GitHub путём опроса, поэтому ноутбук за NAT ведёт себя точно так же, как публичное развёртывание.
Предварительные требования
Заголовок раздела «Предварительные требования»- На сервере зарегистрирован и установлен его GitHub App с разрешениями Pull requests: read and write (для комментариев, веток ревью и реакций) и Issues: read (для поиска комментариев). Оба уже перечислены в списке разрешений того руководства
- Репозиторий привязан к рабочему пространству в Control Center
- Ни URL вебхука, ни туннеля, ни callback — на стороне сети настраивать нечего
Узнать имя бота
Заголовок раздела «Узнать имя бота»Логин бота — <appslug>[bot], где appslug — это имя, которое вы задали
приложению при его регистрации.
- Откройте Настройки → Сервер → Единый вход и прокрутите до карточки Приложения провайдера
- Разверните блок GitHub и нажмите Тест
- Скопируйте Логин бота, когда он подставится. Если по-прежнему показывается
подсказка о пустом значении, логин всегда
<appslug>[bot]— введите его или короткую форму@appslug
GitHub не предлагает аккаунты приложений в своём автодополнении по @, поэтому
логин приходится вводить вручную — именно поэтому карточка настроек позволяет
скопировать его одним нажатием. Суффикс [bot] необязателен: и @myapp, и
@myapp[bot] адресуют бота.
Запросить проверку из GitHub
Заголовок раздела «Запросить проверку из GitHub»Два способа, и оба запускают тот же предустановленный конвейер pr_review, что и
кнопка Спросить AI:
- Добавьте метку
ai-reviewк PR. Это ближайший аналог назначения бота ревьюером из тех, что предлагает GitHub, — аккаунты приложений не могут занимать штатный слот запрошенного ревьюера. Реагировать не на что, поэтому на GitHub ничего не публикуется; проверка запускается в Control Center - Напишите комментарий
@myapp review(или просто@myapp) в разговоре PR. Бот ставит реакцию 👀, а затем отвечает, когда проверка запустилась (или что она уже идёт)
Ревьюеры работают в пространстве проверки этого PR; читайте и публикуйте замечания так, как описано в разделе Использовать ИИ-проверку. Публикация обратно в GitHub остаётся решением, которое вы принимаете в Control Center, — запуск проверки из GitHub сам по себе ничего в GitHub не публикует.
Метка срабатывает один раз на PR: её добавление и есть запрос, и она не взводится заново при удалении и повторном добавлении. Чтобы запустить проверку снова — скажем, после пуша, — упомяните бота.
Задать вопрос
Заголовок раздела «Задать вопрос»Оставьте комментарий в разговоре PR:
@myapp why does the flaky test in runner_test.dart fail on CI but not locally?Что происходит, по порядку:
- Бот ставит реакцию 👀, чтобы вы знали, что комментарий замечен
- Вопрос публикуется в пространстве проверки этого PR от вашего имени — с тем же закреплением авторства, как если бы вы набрали его в Control Center
- Агент отвечает в пространстве, и ответ публикуется обратно в PR комментарием, который @-упоминает вас
Вопрос в PR, где проверка ещё не запускалась, будит CEO-агента рабочего пространства; после запуска проверки отвечает агент, говоривший последним, поэтому последующие вопросы попадают к тому, у кого есть контекст.
Продолжить в ветке ревью
Заголовок раздела «Продолжить в ветке ревью»Ответьте внутри встроенной ветки ревью, в которой участвует бот, — комментария к diff, который он оставил, или ответа, который он опубликовал в этой ветке. Упоминание не нужно; сама ветка и есть адресация:
> @myapp the retry loop looks O(n²) to me
what would the complexity be with the bounded queue instead?Многоходовый диалог работает так же: каждый ответ — это ещё один вопрос в том же разговоре, где контекстом служит пространство проверки, и ответ возвращается в ту же ветку.
Последующий вопрос в ленте разговора PR — это новый комментарий верхнего уровня, поэтому ему всё ещё нужно @-упоминание.
С кем разговаривает бот
Заголовок раздела «С кем разговаривает бот»Комментарий из GitHub приходит, неся немногим больше логина, поэтому, прежде чем что-либо делать, бот сопоставляет автора:
- Ваш аккаунт GitHub должен быть привязан к вашей личности в Control Center — войдите с GitHub или вставьте токен в разделе Настройки → Рабочее пространство → Профиль и идентичность → Хостинг кода
- Вы должны быть участником с ролью на запись (
member,adminилиowner) в рабочем пространстве, к которому привязан репозиторий
Все остальные получают один вежливый ответ с объяснением, чего не хватает, —
неизвестный логин (не привязанный или привязанный, но не состоящий здесь
участником) и роль только для чтения — это два таких случая, — и их слова никогда
не попадают в рабочее пространство. Метка ai-review так не проверяется: у неё нет
автора, поэтому она запускает проверку в рабочем пространстве, которое уже
привязало репозиторий.
Чего ожидать
Заголовок раздела «Чего ожидать»| Что | Поведение |
|---|---|
| Подтверждение | 👀 на комментарии примерно в течение минуты — это интервал обхода. У метки ai-review нет комментария, на который можно реагировать |
| Ответы | Публикуются от имени бота (приложения), в том же разговоре, где был задан вопрос |
| Закрепление авторства в пространстве | Вопрос принадлежит вам; агент работает от вашего имени, согласно настройкам автономии пространства |
| Проверки | Замечания попадают в пространство проверки; публикация в GitHub выполняется вручную |
Задержка примерно в одну минуту — это плата за то, что входящий сетевой доступ не нужен вовсе. В обходе нет ничего срочного, и ничего не теряется, пока сервер офлайн, — комментарий, пришедший во время простоя, подхватывается на следующем обходе.
Устранение неполадок
Заголовок раздела «Устранение неполадок»На комментарий с упоминанием бота ничего не происходит.
- Приложение установлено на аккаунте, которому принадлежит репозиторий, а сам репозиторий привязан к рабочему пространству? Непривязанный репозиторий пропускается до того, как что-либо будет записано, поэтому если привязать его позже, комментарий всё равно доставится
- Ваш аккаунт GitHub привязан, и вы участник с ролью на запись? Посмотрите в PR ответ бота с отказом — в нём сказано, чего именно не хватает
- Всё ещё ничего? При сбое журнал сервера называет обход и PR; ищите
pr_conversation:(опросчик) иgithub_pr_conversation:(мост)
Метка не запускает проверку.
Она срабатывает один раз на PR. Если проверка уже прошла или метка была добавлена
до того, как сервер впервые увидел PR (первый обход молча записывает накопившееся,
а не обрушивает это лавиной), вместо неё упомяните бота — @myapp review всегда
запускает проверку, если только она уже не выполняется.
Ответ бота так и не появился на GitHub.
Сам ответ никогда не теряется — он находится в пространстве проверки этого PR в Control Center. Сбой публикации (GitHub недоступен, разрешения изменились) записывается в журнал, а ответ не повторяется; если это важно, спросите ещё раз в ветке.
Связанные руководства
Заголовок раздела «Связанные руководства»- Создать GitHub App: регистрация, из которой рождается бот
- Использовать ИИ-проверку: как читать замечания, которые производит проверка, запущенная упоминанием
- Настроить интеграцию GitHub: привязка вашего собственного аккаунта GitHub, по которому бот вас сопоставляет
- Использовать пространства: комната, в которой всё это оказывается