Bitbucket Cloud
Трекеры задач · издатель buff · версия 1.0.4
Вопросы и ответы прямо в pull request bitbucket.org — там, где идёт ревью.
Вопрос из pull request в интерфейсе Buff: в ответе есть export.py — файл, который существует только на ветке этого pull request. Форма настройки строится по схеме, которую интеграция объявляет о себе. Подключение работает: свой процесс, свой набор инструментов, свой разрешённый адрес. Проверка связи говорит не «ок», а под какой учётной записью вошли и сколько репозиториев в области. Что интеграция получит, видно в каталоге коннектора до установки.
Нажмите на снимок, чтобы открыть его целиком. Все снимки — с работающей установки.
Обзор
Интеграция связывает Buff с вашим рабочим пространством на bitbucket.org. Разработчик пишет боту в обсуждении pull request — ответ приходит туда же и разобран по коду ИМЕННО этой ветки. Своего трекера задач у Bitbucket Cloud больше нет: Atlassian убрал его из API, поэтому обращения живут в pull request — как и у Bitbucket Data Center, для которого есть отдельная интеграция со своим API. Задачи вашей команды подключаются отдельной интеграцией того трекера, в котором они на самом деле лежат.
Сценарии
Ситуации, ради которых его ставят.
Вопрос по коду прямо в ревью
Ревьюер открыл чужой pull request и не понимает, зачем понадобилась правка сразу в трёх местах. Спрашивать автора — ждать до завтра, читать ветку самому — полдня.
Результат. Он пишет боту в обсуждении. Ответ приходит туда же и разобран по коду ЭТОЙ ветки: что меняется, почему связаны три места и на что это влияет.
Что здесь меняется по существу
Pull request на восемьсот строк, а вопрос простой: что меняется по делу и чего не хватает.
Результат. Бот читает изменения одним diff и отвечает по существу — что меняется, что осталось недоделанным, где тесты не покрывают новую ветку кода.
Задачи лежат в другом трекере
Своего трекера у Bitbucket Cloud больше нет — Atlassian убрал его, — а задачи команды живут в Jira, GitLab или Redmine.
Результат. Ревью остаётся в Bitbucket, задачи — там, где они есть: интеграция того трекера ставится рядом, и бот отвечает в обоих местах. Подключений может быть сколько угодно.
Ответ там, где его ждут
Заказчик правки не заходит в интерфейс Buff и не собирается. Ему нужен ответ в том обсуждении, которое он открыл.
Результат. Готовый разбор или ссылка на задачу разработки приходит комментарием туда же. Единственный инструмент интеграции, который что-то пишет, — и он недоступен на стадиях, где модель только читает.
Примеры
Что написать и что придёт в ответ. Обращение к боту задаётся в настройках подключения — здесь это «@buff».
@buff, что меняет этот pull request и чего в нём не хватает?
комментарий в обсуждении pull request
инструмент:
get_pull_diffВетка добавляет сборку выгрузки в CSV: новый модуль export.py, который берёт товары в наличии и считает цену со скидкой. Не хватает тестов на пустой каталог и на товар без скидки; заголовок ответа отдаётся без charset — на кириллице это тот же старый баг.
@buff, зачем здесь понадобился отдельный кеш?
комментарий в обсуждении pull request
инструмент:
get_pullПрочитал pull request вместе с обсуждением: кеш появился после жалобы на задержку выгрузки, обсуждали два варианта и выбрали этот, чтобы не трогать общий слой. В описании это есть только одной строкой, остальное — в комментариях.
/task доделать тесты на пустой каталог
комментарий в обсуждении pull request
инструмент:
get_pullСлово после обращения выбирает работу: без него — короткий ответ, «research» — глубокое исследование с документом, «task» — черновик задачи разработки со ссылкой обратно в это обсуждение.
@buff, найди pull request про кеширование каталога
комментарий в любом отмеченном репозитории
инструмент:
search_pullsНашёл три: открытый «TTL для кеша каталога», влитый «прогрев кеша после деплоя» и закрытый без слияния — там от кеша отказались в пользу материализованного представления, и это стоит прочитать до того, как повторять.
Что умеет
Отвечает по ветке того pull request, где спросили
Вопрос в обсуждении pull request — это вопрос про код ЭТОЙ ветки. Интеграция передаёт ветку вместе с обращением, Buff подтягивает её из вашего репозитория и считает ответ на ней. Ответ по основной ветке на вопрос про изменения — это не ответ, а совпадение.
Читает pull request и задачу целиком
get_pull отдаёт модели описание и всё обсуждение — то, из чего складывается настоящий замысел изменения. get_pull_diff приносит изменения одним diff. Оба только читают.
Ищет по отмеченным репозиториям
search_pulls ходит только по репозиториям, которые вы отметили, и находит связанные pull request и задачи. Тоже только чтение.
Отвечает там же, где спросили
add_comment пишет ответ в то же обсуждение. Это единственный инструмент интеграции, который что-то меняет, — и он недоступен на стадиях, где модель только читает. Проверяет это коннектор у себя.
Знает, как к нему обращаются в Bitbucket
В Bitbucket Cloud у человека нет логина в привычном смысле: есть отображаемое имя, ник и идентификатор учётной записи, а редактор вставляет упоминание как `@{id}`. Интеграция узнаёт себя во всех трёх видах — и поэтому не принимает собственный ответ за новый вопрос.
Берётся за работу только по обращению
Одобрение, смена статуса задачи или назначение ревьюера не запускают ничего. Список отмеченных репозиториев и есть контроль доступа: внутри них позвать бота может любой участник, за их пределами — никто.
Как пользоваться
Всё происходит на машине, где стоит коннектор. Открывать доступ к вашей сети снаружи не нужно ни на одном шаге.
Шаг 1
Установка занимает одно нажатие
Откройте раздел «Маркетплейс» на локальной странице коннектора. До установки видно, что интеграция получит: адреса, по которым она сможет ходить, какие учётные данные попросит и сколько инструментов увидит модель. Коннектор скачивает подписанный бандл из нашего реестра и проверяет подпись до того, как что-то запишет на диск.
КоннекторГраницы доступа видны в каталоге до установки. Шаг 2
Настройка — учётная запись, токен и список репозиториев
Адрес API уже подставлен (`https://api.bitbucket.org`) — он существует как поле ровно затем, чтобы было видно, куда ходит интеграция. Дальше нужны учётная запись бота и её пароль приложения (или API-токен), а также репозитории в виде `пространство/репозиторий`. Секрет хранится на вашей машине; интеграция его не видит.
КоннекторФорма настройки строится по схеме интеграции. Шаг 3
Заведите боту отдельную учётную запись
Пригласите её в рабочее пространство и дайте доступ только к нужным репозиториям: права учётной записи — внешняя граница, а список отмеченных репозиториев — внутренняя. Паролю приложения достаточно прав на чтение репозиториев и запись в pull request и задачи.
Шаг 4
То же самое из командной строки
Установка без графики равноправна, а не запасной вариант: `connector install bitbucket-cloud`, затем `connector instance add bitbucket-cloud --config base_url=https://api.bitbucket.org --config repos=acme/api`.
Шаг 5
События приходят сами
После настройки ничего запускать не нужно: интеграция сама следит за отмеченными репозиториями. Хотите быстрее — включите приём событий у коннектора и добавьте в Bitbucket вебхук на комментарии к pull request и задачам. Bitbucket Cloud свои вызовы не подписывает, поэтому пропуском служит секрет в самой ссылке — коннектор выдаёт её сам и никому больше не показывает.
КоннекторКаждое подключение — отдельный процесс со своим набором инструментов.
Границы доступа
То же самое коннектор показывает на вашей машине до установки. Список берётся из подписанного каталога, а не написан здесь руками.
Ходит наружу
только по адресам из полей base_url
Учётные данные
api — значения остаются в коннекторе, интеграция их не видит
Вебхуки
deliver — порт открываете вы, по желанию
| Инструмент | Что делает | Доступ |
|---|---|---|
| search_pulls | Найти pull request по тексту — когда упомянут номер или нужен контекст из ревью | только чтение |
| get_pull | Прочитать pull request с обсуждением — когда нужен замысел изменения или ход ревью | только чтение |
| get_pull_diff | Прочитать изменения pull request одним diff | только чтение |
| add_comment | Написать комментарий в pull request | пишет |
Интеграция работает отдельным процессом под собственным пользователем операционной системы: она не видит ключа коннектора, не читает файлы других подключений и не может выйти в сеть мимо коннектора. Подробнее — в разделе о безопасности.
Требования
- Bitbucket Cloud (bitbucket.org). Для Data Center и Server — отдельная интеграция: у них другой API.
- Учётная запись бота в вашем рабочем пространстве и её пароль приложения или API-токен с правом читать репозитории и писать комментарии.
- Сетевой доступ от машины с коннектором до bitbucket.org — наружу из вашей сети ничего открывать не нужно.
- Коннектор, запущенный с правом заводить отдельного пользователя ОС для интеграции (root или CAP_SETUID).
- Чтобы ответы разбирались по коду, подключите те же репозитории к Buff как источник кода — тем же коннектором, в разделе «Репозитории».
Вопросы
- У нас Bitbucket Server, а не облако. Подойдёт?
- Нет, для Data Center и Server есть отдельная интеграция — у них другой API. На витрине она называется Bitbucket Data Center.
- Пароль приложения уходит к вам в облако?
- Нет. Он хранится на машине с коннектором и не покидает её. Интеграция тоже его не видит: коннектор подставляет его в исходящий запрос сам.
- У части репозиториев трекер задач выключен. Это сломает интеграцию?
- Нет. Там, где трекера нет, интеграция просто работает в pull request. Проверка связи прямо говорит, у скольких отмеченных репозиториев трекер включён.
- Bitbucket не подписывает вебхуки. Как вы отличаете чужой вызов?
- Пропуском служит секрет внутри самой ссылки — её выдаёт коннектор, она не угадывается и не показывается никому, кроме вас. Вызов с неверной ссылкой не доходит до интеграции вовсе.
- Бот будет менять статусы и закрывать задачи?
- Нет. Интеграция читает и пишет комментарии. Статусы, ревьюеры и слияние остаются за вашей командой.
Дальше
Подключить Bitbucket Cloud
Поставьте коннектор в своей сети, откройте его локальную страницу и установите интеграцию из каталога. Пересобирать ничего не нужно.
Юрлицам и ИП — оплата переводом по реквизитам и закрывающие документы