GitHub
Подключение приложения, репозитории проекта, режимы работы с git, проверки и приёмка.
Связь с GitHub — не украшение: от неё зависит, как агент отдаёт работу и можно ли эту работу принять.
Подключение приложения
Подключается один раз на организацию, а не на каждый проект.
- Настройки организации → раздел «GitHub» → «Подключить».
- GitHub спросит, куда установить приложение и к каким репозиториям дать доступ.
- После установки вас вернёт обратно, и в разделе появится установка со списком репозиториев.
Почему не спрашивают, какую организацию выбрать
Если приложение уже установлено в одну из ваших организаций, GitHub ведёт сразу в её настройки. Чтобы поставить его в другую организацию, на странице установки выберите её в списке аккаунтов — или пройдите по ссылке установки, когда ни одной установки ещё нет.
Права, которые запрашивает приложение, намеренно скромные: чтение кода, запись в pull request и комментарии, чтение проверок. Записи в код нет — ветку отправляет клиент под правами человека, платформа только открывает pull request и комментирует.
Репозиторий проекта
После подключения организации в настройках проекта выбирается репозиторий — из списка, а не строкой.
Это не про удобство. Раньше адрес вводили руками, и по чужому адресу можно было увидеть коммиты и pull request'ы, к которым доступа нет. Список показывает только то, к чему приложение реально имеет доступ.
Два режима работы с git
Задаётся в настройках проекта.
| Режим | Что делает агент |
|---|---|
| Прямой | Работает в ветке и отправляет её в репозиторий. Pull request не создаётся. |
| Pull request | Платформа открывает pull request по результату работы и ведёт его. |
Имя ветки собирается по шаблону проекта — в него подставляются ключ задачи и её заголовок. В карточке задачи видно, какая ветка используется; если pull request уже открыт, показывается настоящая ветка из него, а не ожидаемая по шаблону.
Написано, но вживую не проверено
Режим pull request собран, покрыт тестами и выложен, но полный цикл на настоящем репозитории — агент сделал работу, платформа открыла pull request, проверки прошли, задача принята — человеком ещё не прогонялся.
Привязка коммитов к задачам
Коммит привязывается к задаче строкой в конце сообщения:
Quiel-Task: ATL-42Клиент добавляет её сам. После отправки коммит появляется в карточке задачи. Повторная доставка того же события ссылку не дублирует.
Проверки и приёмка
В карточке задачи под результатом стоит карточка GitHub: pull request с его состоянием и веткой, а под ним — проверки GitHub Actions со сводкой «сколько из скольких».
Проверки показываются по последнему коммиту ветки, а не вперемешку за всю историю: каждый push запускает новый прогон, и интересен последний.
Незелёные проверки не дают принять задачу
Если по последнему коммиту pull request'а проверки не прошли или ещё идут, кнопка приёмки откажет. Это не предупреждение, которое можно пролистать, — сервер откажет, даже если нажать в обход интерфейса.
Рядом стоит строка «По отчёту агента» — что сам агент написал про тесты и на что сослался. Это отдельные сведения, а не то же самое: агент может написать «тесты пропущены», когда Actions при этом зелёные. Расхождение между заявленным и наблюдаемым — как раз то, ради чего человек и смотрит на задачу перед приёмкой.
Автоприёмка по слиянию
В настройках проекта включается автоприёмка: когда pull request влит, задача сама переходит в «Готово».
Включать стоит, если ревью у вас и так происходит в GitHub — иначе получится две приёмки подряд. Если ревью ведётся в quiel, оставьте выключенной.
Задачи из GitHub Issues
Issue можно перенести в задачу проекта: заголовок, текст и метки переедут. Обратная ссылка остаётся, чтобы было видно, откуда задача взялась.