Bitbucket Data Center

Своего трекера задач у Bitbucket Data Center нет — команды держат задачи в другом месте, а в Bitbucket ведут код. Поэтому интеграция живёт там, где работа: в pull request. Разработчик пишет боту в обсуждении, ответ приходит туда же и разобран по коду ИМЕННО этой ветки, а не по основной.

• Вопрос по коду прямо в ревью

  Ревьюер открыл чужой pull request и не понимает, зачем понадобилась правка в трёх местах сразу. Спрашивать автора — ждать до завтра, читать всю ветку самому — полдня.

  Результат. Он пишет боту в обсуждении. Ответ приходит туда же и разобран по коду ЭТОЙ ветки: что меняется, почему связаны три места и на что это влияет. Ревью продолжается в том же окне.

• Что здесь меняется по существу

  Pull request на восемьсот строк, а вопрос простой: что меняется по делу и чего не хватает.

  Результат. Бот читает изменения одним diff и отвечает по существу — что меняется, что осталось недоделанным, где тесты не покрывают новую ветку кода. Ответ лежит в самом pull request, рядом с изменениями.

• Задача разработки из обсуждения ревью

  В ревью выяснилось, что правку нужно доделать отдельно, и это надо куда-то записать, пока не забылось.

  Результат. Buff заводит черновик задачи разработки по обсуждению и возвращает ссылку комментарием. Ревью не превращается в переписку о том, кто заведёт задачу.

• Это уже было — найти, где именно

  Изменение подозрительно похоже на прошлогоднее, но помнит его только тот, кто в отпуске.

  Результат. Интеграция ищет по отмеченным репозиториям и приносит связанные pull request — прошлые заходы на ту же подсистему, изменения, на которые опирается текущее.

1. @buff перечисли, что меняет этот pull request, и чего в нём не хватает

   комментарий в pull request

   инструмент: get_pull_diff

   Меняет три места: разбор CSV (добавлен BOM), заголовок ответа (появился charset=utf-8) и тест выгрузки. Не хватает: выгрузка из планировщика идёт другим путём и BOM там не добавляется — файл из ночной задачи откроется так же криво.

2. /research разберись, откуда берётся задержка в отчёте

   комментарий в pull request — так запускается глубокое исследование

   инструмент: get_pull

   Слово после обращения выбирает работу: без него — короткий ответ, «research» — глубокое исследование с документом, «task» — черновик задачи разработки. Команда через слэш тоже работает.

3. @buff что уже обсуждали в этом ревью?

   комментарий в pull request с длинной перепиской

   инструмент: get_pull

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

4. @buff найди pull request про кеширование каталога

   комментарий в любом pull request отмеченного репозитория

   инструмент: search_pulls

   Нашёл 3 захода на кеширование: • ACME/api!218 «Сброс кеша каталога после смены цены» — влит • ACME/api!341 «Прогрев кеша после деплоя» — влит • ACME/api!402 «Дубли в выдаче после инвалидации» — открыт, похоже на текущее

1. Шаг 1

   Установка занимает одно нажатие

   Откройте раздел «Маркетплейс» на локальной странице коннектора. До установки видно, что интеграция получит: адреса, по которым она сможет ходить, какие учётные данные попросит, будет ли принимать вызовы и сколько инструментов увидит модель. Коннектор скачивает подписанный бандл из нашего реестра и проверяет подпись до того, как что-то запишет на диск.

   Коннектор

   

2. Шаг 2

   Настройка — адрес, токен и список репозиториев

   Нужен адрес вашего Bitbucket, HTTP access token учётной записи бота и репозитории в формате КЛЮЧПРОЕКТА/репозиторий. Форма построена по схеме, которую интеграция объявляет о себе. Токен остаётся в коннекторе: интеграция его не видит.

   Коннектор

   

3. Шаг 3

   Заведите боту отдельную учётную запись

   Дайте ей доступ только к тем репозиториям, где бот должен отвечать: права учётной записи — это внешняя граница, а список отмеченных репозиториев — внутренняя. Прав на чтение и комментирование достаточно; администратором бот быть не должен. Токен создаётся под самим ботом — Bitbucket не позволяет администратору выпустить токен за другого.

4. Шаг 4

   То же самое из командной строки

   Установка без графики равноправна, а не запасной вариант: `connector install bitbucket-dc`, затем `connector instance add bitbucket-dc --config base_url=… --config repos=ACME/api`.

5. Шаг 5

   События приходят сами

   После настройки ничего запускать не нужно: интеграция сама следит за отмеченными репозиториями. Хотите быстрее — включите приём событий у коннектора и добавьте в Bitbucket вебхук на событие «Pull request → comment added»; ссылку и секрет коннектор выдаёт сам, а подпись Bitbucket (`X-Hub-Signature`) он проверяет.

   Коннектор

   

Интеграция работает отдельным процессом под собственным пользователем операционной системы: она не видит ключа коннектора, не читает файлы других подключений и не может выйти в сеть мимо коннектора. Подробнее — в разделе о безопасности.

• Bitbucket Data Center или Server — облачный bitbucket.org это другая интеграция, у него другой API.
• HTTP access token учётной записи бота с правом читать и комментировать нужные репозитории.
• Сетевой доступ от машины с коннектором до Bitbucket — наружу из вашей сети ничего открывать не нужно.
• Коннектор, запущенный с правом заводить отдельного пользователя ОС для интеграции (root или CAP_SETUID).
• Своего трекера задач у Bitbucket DC нет: интеграция работает в pull request. Если задачи у вас в Jira или Redmine — поставьте рядом их интеграцию.

А задачи? Мы не нашли трекер.

Его и нет: у Bitbucket Data Center нет собственного трекера задач. Эта интеграция работает в pull request, а для задач поставьте интеграцию того трекера, где они у вас живут.

Токен Bitbucket уходит к вам в облако?

Нет. Он хранится на машине с коннектором и не покидает её. Интеграция тоже его не видит: коннектор подставляет токен в исходящий запрос сам.

Может ли интеграция ходить куда-то, кроме нашего Bitbucket?

Нет. Наружу она ходит только через коннектор и только по адресу, выведенному из поля настройки, и только по путям REST API. Всё остальное коннектор отклоняет.

Бот сможет писать в репозитории, которые мы не отмечали?

Нет. Список отмеченных репозиториев ограничивает и чтение, и запись: обращение из неотмеченного репозитория не запускает работу, а попытка ответить туда отклоняется самим коннектором.

Вопрос разбирается по ветке pull request или по основной?

По ветке этого pull request. Обращение приносит репозиторий и ветку, платформа подтягивает свежую копию репозитория и разбирает вопрос на ней. Если репозиторий не подключён к Buff как источник кода, бот ответит по основной ветке и скажет об этом в самом обсуждении.

Может ли бот начать работу сам, без обращения?

Нет. Ни аппрув, ни новый коммит, ни смена статуса не считаются обращением — работу начинает только упоминание или команда в комментарии.

Может ли модель случайно написать в ревью на этапе анализа?

Нет. Инструменты доступны только на читающих стадиях и только те, что помечены как читающие. add_comment туда не попадает, и проверяет это коннектор у себя.

Нужно ли открывать порт для вебхуков?

Не обязательно. Опрос работает всегда и портов не требует; приём вызовов — ускорение для тех, кому есть куда его направить. Порт открывает коннектор, один на все подключения.