# GitHub — интеграция для Buff

> Вопросы и ответы прямо в задачах и pull request GitHub — и в облаке github.com, и в Enterprise Server внутри вашей сети.

[Маркетплейс](https://buff.systems/marketplace) GitHub

# GitHub

Трекеры задач · издатель buff · версия 1.0.4

Вопросы и ответы прямо в задачах и pull request GitHub — и в облаке github.com, и в Enterprise Server внутри вашей сети.

[Скачать коннектор](https://buff.systems/downloads) [Как установить](https://buff.systems/#usage) 3 из 4 инструментов только читают

- Вопрос из pull request в интерфейсе Buff: в ответе есть export.py — файл, который существует только на ветке этого pull request.
- Форма настройки строится по схеме, которую интеграция объявляет о себе.
- Подключение работает: свой процесс, свой набор инструментов, свой разрешённый адрес.
- Проверка связи говорит не «ок», а где вы, под какой учётной записью вошли и сколько репозиториев в области.
- Что интеграция получит, видно в каталоге коннектора до установки.

Нажмите на снимок, чтобы открыть его целиком. Все снимки — с работающей установки.

## Обзор

Интеграция связывает Buff с вашим GitHub. Команда продолжает работать там, где привыкла: в задаче и в обсуждении pull request. Вопрос, заданный под pull request, разбирается по коду ИМЕННО его ветки — а не по основной, — и ответ приходит комментарием туда же. Одна и та же интеграция работает с github.com и с GitHub Enterprise Server: API у них один, отличается только адрес.

## Сценарии

Ситуации, ради которых его ставят.

- ### Вопрос по коду прямо в ревью Ревьюер открыл чужой pull request и не понимает, зачем понадобилась правка сразу в трёх местах. Спрашивать автора — ждать до завтра, читать ветку самому — полдня. Результат. Он пишет боту в обсуждении. Ответ приходит туда же и разобран по коду ЭТОЙ ветки: что меняется, почему связаны три места и на что это влияет. Ревью продолжается в том же окне.
- ### Вопрос по коду, не выходя из задачи Тестировщик завёл issue «экспорт в CSV ломается на кириллице» и не знает, где копать. Результат. Он упоминает бота в комментарии. Через несколько минут в задаче лежит разбор: где формируется выгрузка, почему теряется кодировка и что придётся менять.
- ### Что здесь меняется по существу Pull request на восемьсот строк, а вопрос простой: что меняется по делу и чего не хватает. Результат. Бот читает изменения одним diff и отвечает по существу — что меняется, что осталось недоделанным, где тесты не покрывают новую ветку кода. Ответ лежит рядом с изменениями.
- ### Ответ там, где его ждут Заказчик задачи не заходит в интерфейс Buff и не собирается. Ему нужен ответ в задаче, которую он открыл. Результат. Готовый разбор или ссылка на задачу разработки приходит комментарием в исходную задачу. Единственный инструмент интеграции, который что-то пишет, — и он недоступен на стадиях, где модель только читает.

## Примеры

Что написать и что придёт в ответ. Обращение к боту задаётся в настройках подключения — здесь это «@buff».

1. @buff, что меняет этот pull request и чего в нём не хватает? комментарий в обсуждении pull request инструмент: `get_pull_diff` Ветка добавляет сборку выгрузки в CSV: новый модуль export.py, который берёт товары в наличии и считает цену со скидкой. Не хватает тестов на пустой каталог и на товар без скидки; заголовок ответа отдаётся без charset — на кириллице это тот же старый баг.
2. @buff, разберись, почему при экспорте ломается кириллица комментарий в задаче инструмент: `get_issue` Прочитал задачу целиком, вместе с обсуждением, и разобрал по коду. Файл отдаётся без BOM и с заголовком text/csv без charset — Excel в Windows читает такой файл в cp1251. Разбор с местами в коде приложил документом и продублировал ссылкой сюда.
3. /research откуда берётся задержка в выгрузке комментарий в задаче или pull request инструмент: `get_issue` Слово после обращения выбирает работу: без него — короткий ответ, «research» — глубокое исследование с документом, «task» — черновик задачи разработки. Привычная команда через слэш работает так же, как обращение по имени.
4. @buff, найди задачи про кеширование каталога комментарий в любом отмеченном репозитории инструмент: `search_issues` Нашёл 4 обращения по кешированию: две закрытые задачи про сброс кеша после смены цены и прогрев после деплоя, открытый pull request про TTL и задачу про дубли в выдаче — она похожа на текущую.

## Что умеет

### Отвечает по ветке того pull request, где спросили

Вопрос в обсуждении pull request — это вопрос про код ЭТОЙ ветки. Интеграция передаёт ветку вместе с обращением, Buff подтягивает её из вашего репозитория и считает ответ на ней. Ответ по основной ветке на вопрос про изменения — это не ответ, а совпадение.

### Читает задачу и pull request целиком

get\_issue отдаёт модели описание и всё обсуждение — то, из чего складывается настоящая постановка: в заголовке «не работает поиск», а в третьем комментарии то, что именно и на каких данных. get\_pull\_diff приносит изменения одним diff. Оба только читают.

### Ищет по отмеченным репозиториям

search\_issues ходит только по репозиториям, которые вы отметили, и находит связанные задачи и pull request — дубликаты, прошлые обращения по той же подсистеме, изменения, на которые опирается текущее. Тоже только чтение.

### Отвечает там же, где спросили

add\_comment пишет ответ в ту же задачу или pull request. Это единственный инструмент интеграции, который что-то меняет, — и он недоступен на стадиях, где модель только читает. Проверяет это коннектор у себя.

### Берётся за работу только по обращению

Метка, смена статуса или ревью-запрос не запускают ничего: их ставят правила и массовые правки, и работа, которую никто не заказывал, всё равно была бы оплачена. Назначение задачи на учётную запись бота — это обращение, но и оно бывает автоматическим, поэтому включается отдельной настройкой. Список отмеченных репозиториев и есть контроль доступа: внутри них позвать бота может любой участник, за их пределами — никто.

### Никогда не трогает ваш процесс

Интеграция не меняет статусы, не двигает задачи по доске, не назначает исполнителей и не закрывает issue. Она читает и пишет комментарии — ничего больше. Ваш процесс остаётся вашим.

## Как пользоваться

Всё происходит на машине, где стоит коннектор. Открывать доступ к вашей сети снаружи не нужно ни на одном шаге.

1. Шаг 1 ### Установка занимает одно нажатие Откройте раздел «Маркетплейс» на локальной странице коннектора. До установки видно, что интеграция получит: адреса, по которым она сможет ходить, какие учётные данные попросит и сколько инструментов увидит модель. Коннектор скачивает подписанный бандл из нашего реестра и проверяет подпись до того, как что-то запишет на диск. **Коннектор** Границы доступа видны в каталоге до установки.
2. Шаг 2 ### Настройка — адрес, токен и список репозиториев Для github.com адрес API уже подставлен (\`https://api.github.com\`), для Enterprise Server укажите \`https://ваш-сервер/api/v3\`. Дальше — токен учётной записи бота и репозитории в виде \`владелец/репозиторий\`. Токен хранится на вашей машине; сама интеграция его не видит — коннектор подставляет его в исходящий запрос сам. **Коннектор** Форма настройки строится по схеме интеграции.
3. Шаг 3 ### Заведите боту отдельную учётную запись На github.com это machine account — то, что правила прямо разрешают. Дайте ему доступ только к тем репозиториям, где бот должен отвечать: права учётной записи — внешняя граница, а список отмеченных репозиториев — внутренняя. Классический токен со скоупом \`repo\` или fine-grained с правами на содержимое, задачи и pull request.
4. Шаг 4 ### То же самое из командной строки Установка без графики равноправна, а не запасной вариант: \`connector install github\`, затем \`connector instance add github --config base\_url=https://api.github.com --config repos=acme/api\`. На сервере без иксов вы делаете то же самое и получаете тот же результат.
5. Шаг 5 ### События приходят сами После настройки ничего запускать не нужно: интеграция сама следит за отмеченными репозиториями. Хотите быстрее — включите приём событий у коннектора и добавьте в GitHub webhook на события Issue comments и Pull request review comments; ссылку и секрет коннектор выдаёт сам, а подпись GitHub (\`X-Hub-Signature-256\`) он проверяет. **Коннектор** Каждое подключение — отдельный процесс со своим набором инструментов.

## Границы доступа

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

Ходит наружу

только по адресам из полей `base_url`

Учётные данные

api — значения остаются в коннекторе, интеграция их не видит

Вебхуки

deliver — порт открываете вы, по желанию

| Инструмент | Что делает | Доступ |
| --- | --- | --- |
| search\_issues | Найти задачи и pull request по тексту — когда упомянут номер или нужен контекст из трекера | только чтение |
| get\_issue | Прочитать задачу или pull request с обсуждением — когда нужны требования или ход обсуждения | только чтение |
| get\_pull\_diff | Прочитать изменения pull request одним diff | только чтение |
| add\_comment | Написать комментарий в задачу или pull request | пишет |

Интеграция работает отдельным процессом под собственным пользователем операционной системы: она не видит ключа коннектора, не читает файлы других подключений и не может выйти в сеть мимо коннектора. Подробнее — в [разделе о безопасности](https://buff.systems/security).

## Требования

- GitHub — github.com или Enterprise Server; API у них один, различается только адрес.
- Токен учётной записи бота с правом читать репозитории и писать комментарии в задачах и pull request.
- Сетевой доступ от машины с коннектором до GitHub — наружу из вашей сети ничего открывать не нужно.
- Коннектор, запущенный с правом заводить отдельного пользователя ОС для интеграции (root или CAP\_SETUID).
- Чтобы ответы разбирались по коду, подключите те же репозитории к Buff как источник кода — тем же коннектором, в разделе «Репозитории».

## Вопросы

- **Токен GitHub уходит к вам в облако?**: Нет. Он хранится на машине с коннектором и не покидает её. Интеграция тоже его не видит: коннектор подставляет токен в исходящий запрос сам.
- **Может ли интеграция ходить куда-то, кроме нашего GitHub?**: Нет. Адрес, по которому ей разрешено ходить, выводится из вашего же поля «Адрес API», и коннектор не выпускает запрос за его пределы. Что именно разрешено, видно в каталоге до установки.
- **Бот будет менять статусы и закрывать задачи?**: Нет. Интеграция читает и пишет комментарии. Статусы, метки, исполнители и закрытие задач остаются за вашей командой.
- **Enterprise Server у нас внутри сети, наружу закрыт. Заработает?**: Да, для этого коннектор и нужен: он стоит внутри вашего периметра, сам ходит в ваш GitHub и сам дозванивается до Buff. Входящих подключений в вашу сеть не требуется.
- **Бот ответит на комментарий, который написал сам?**: Нет. Он знает свою учётную запись и не принимает собственные ответы за новые вопросы.

Коротко

- **Версия**: 1.0.4
- **Издатель**: buff
- **Обновлён**: 2026-09-06
- **Размер**: 20 КБ
- **Инструментов**: 4, только читают 3
- **Учётные данные**: api
- **Вебхуки**: deliver
- **Платформы**: linux-x86\_64, linux-aarch64

[Документация коннектора](https://buff.systems/docs/connector) [Как это устроено с точки зрения ИБ](https://buff.systems/security) [Задать вопрос об интеграции](https://buff.systems/contact)

На этой странице

- [Обзор](https://buff.systems/#overview)
- [Сценарии](https://buff.systems/#use-cases)
- [Примеры](https://buff.systems/#examples)
- [Что умеет](https://buff.systems/#abilities)
- [Как пользоваться](https://buff.systems/#usage)
- [Границы доступа](https://buff.systems/#access)
- [Требования](https://buff.systems/#requirements)
- [Вопросы](https://buff.systems/#faq)

Дальше

## Подключить GitHub

Поставьте коннектор в своей сети, откройте его локальную страницу и установите интеграцию из каталога. Пересобирать ничего не нужно.

[Скачать коннектор](https://buff.systems/app) [Написать нам](mailto:info@buff.systems)

Юрлицам и ИП — оплата переводом по реквизитам и закрывающие документы