Спілкуватися з Control Center з GitHub PR

Цей посібник показує, як працювати з Control Center, не виходячи з GitHub: попросіть ШІ-рев’ю зі сторінки PR, поставте ботові запитання в коментарі та продовжте розмову в гілках його рев’ю.

Бот — це власний GitHub App вашого сервера, той самий, який уже авторизує людей і виконує фонову роботу. Нічого нового не реєструється, і ніщо не має бути доступним з інтернету: сервер дізнається про сказане на GitHub через опитування, тож ноутбук за NAT поводиться точно як публічне розгортання.

Передумови

Сервер має свій GitHub App зареєстрований і встановлений, з дозволами Pull requests: read and write (для коментарів, гілок і реакцій) та Issues: read (для пошуку коментарів). Обидва вже є в списку дозволів того посібника
Репозиторій пов’язано з робочим простором у Control Center
Жодної URL webhook, жодного тунелю, жодного зворотного виклику — на боці мережі налаштовувати нічого

Знайдіть ім’я бота

Логін бота — <appslug>[bot], де appslug — це назва, яку ви дали застосунку під час реєстрації.

Перейдіть у Налаштування → Сервер → Єдиний вхід і прокрутіть до картки Застосунки провайдера
Розгорніть блок GitHub і натисніть Тест
Скопіюйте Логін бота, коли він з’явиться. Якщо там усе ще порожня підказка, логін завжди <appslug>[bot] — введіть його або коротку форму @appslug

GitHub не пропонує облікові записи застосунків у своєму автодоповненні після @, тож логін доводиться вводити вручну — саме тому картка налаштувань дає змогу скопіювати його одним кліком. Суфікс [bot] необов’язковий: і @myapp, і @myapp[bot] адресують бота.

Запросіть рев’ю з GitHub

Два способи, і обидва запускають той самий вбудований конвеєр pr_review, який запускає кнопка Запитати AI:

Додайте мітку ai-review до PR. Це найближче до призначення бота рецензентом, що GitHub узагалі пропонує — облікові записи застосунків не можуть займати рідне місце запитаного рецензента. Тут немає коментаря, на який реагувати, тож на GitHub нічого не публікується; рев’ю починається в Control Center
Напишіть коментар @myapp review (або просто @myapp) у розмові PR. Бот реагує 👀, а потім відповідає, коли рев’ю почалося (або що воно вже виконується)

Рецензенти працюють у просторі рев’ю цього PR; читайте та публікуйте знахідки, як описано в Використовувати ШІ-перевірку. Публікація назад на GitHub залишається рішенням, яке ви ухвалюєте в Control Center — запуск рев’ю з GitHub сам собою нічого на GitHub не публікує.

Мітка спрацьовує один раз на PR: її додавання і є запитом, і вона не зводиться знову, коли її зняти й додати повторно. Щоб запустити рев’ю ще раз — скажімо, після push — згадайте бота.

Поставте запитання

Напишіть коментар у розмові 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 — саме за ним бот вас зіставляє
Використовувати простори: кімната, у якій усе це відбувається