Jenkins+Bitbucket Pull Request CI

27 Mar 2017

jenkins bitbucket cicd devops

Данная заметка касается реализации варианта CI для fast-forward merging.

Алгоритм работы механизма CI в данном случае: Следуя подходу Git-flow, разработчик создает новый бранч (например new_feature) для реализации какой-либо функциональности. Выполнив работу, он отправляет результат в Bitbucket и создает там pull request (new feature → master). Этот pull request не может быть одобрен (т.е. невозможно сделать merge), пока не получится выполнить удачную сборку. В результате создания (обновления, либо открытия заново) pull-request`а срабатывает триггер, и Jenkins выполняет билд той ветки, которая должна быть слита. В нашем случае, настоящего слияния не происходит, а происходит перемотка, индекс перемещается на последний коммит (результат fast-forward). Таким образом, результат слияния веток более контролируем.

Как всё это настроить: Установить необходимые плагины для Bitbucket и Jenkins:

• Pull Request Notifier for Atlassian Bitbucket (позволяет Jenkins информировать Bitbucket о результате сборки pull request)

• Bitbucket (Stash) Notifier Plugin for Jenkins (позволяет Jenkins уведомить Bitbucket о результате сбоки)

Существуют плагины для Jenkins, позволяющие тесней интегрировать его с Bitbucket, но они подразумевают использование OAuth, как единственный механизм для входа в Jenkins (странный подход к конфигурации: глобальная аутентификация для всего в системе без возможности разделения). Данный вариант не подходит, поскольку наша конфигурация предусматривает использование Crowd-аутентификации, и ее отключение непозволительно. Но для обеспечения pull-request CI достаточно двух плагинов. Подразумевается, что остальные плагины, например, связанные с git, уже установлены.

Отключить в Jenkins “Prevent Cross Site Request Forgery exploits” (в Configure Global Security), чтобы обеспечить связь Jenkins и Bitbucket без использования Crumb. В противном случае необходимо выполнить настройку для использования плагинами Crumb (например, это описано в этой инструкции). В нашем же случае достаточно использования токенов в качестве гарантии безопасности.

Настройка сборки в Jenkins Несколько слов о важных параметрах сборки:

• В случае использования Project-based security полный доступ к билду можно оставить только администратор-у(ам). Bitbucket будет стучаться в Jenkins без учетной записи (используя лишь токен), поэтому необходимо разрешить анонимным пользователям Credentials=View, Job=Build, Job=Read
• Передаваемые переменные - это переменные, связанные с параметрами pull request`а, которые в POST-запросе передает Pull Request Notifier for Atlassian Bitbucket. Используемые в билде:
  • ${PULL_REQUEST_FROM_BRANCH} - название ветки, для которой создан pull request. Используется в скрипте сборки для переключения в эту ветку.
  • ${PULL_REQUEST_FROM_REPO_NAME} - название самого репозитория, может использоваться в скрипте сборки, либо для email и проч.
  • ${PULL_REQUEST_FROM_HASH} - хеш коммита пулл реквеста, его билд отошлет обратно Bitbucket вместе с результатом сборки.
  • ${PULL_REQUEST_URL} - url-адрес пулл реквеста в Bitbucket, используется для email и проч.
  • ${PULL_REQUEST_TITLE} - название пулл реквеста, используется для email и проч.
  • ${PULL_REQUEST_USER_DISPLAY_NAME} - полное имя создателя пулл реквеста, используется для email и проч.
  • ${PULL_REQUEST_USER_EMAIL_ADDRESS} - его почтовый адрес, используется для email и проч.
  • ${PULL_REQUEST_AUTHOR_EMAIL} - я так понимаю, это адрес владельца репозитория (?), используется для email и проч.
  • ${PULL_REQUEST_REVIEWERS_EMAIL} - почтовые адреса ревьюиров, используется для email и проч.
• Раздел Build Triggers → включить Trigger builds remotely (e.g., from scripts). Добавить произвольный токен, с которым Bitbucket будет делать запрос (чем сложнее, тем лучше, естественно).
• Set Build Name - опционально.
• Build: собственно, ваш способ сборки.
• Post-build Actions:
  • Editable Email Notification, - используются полезные параметры, полученные Jenkins через триггер, упомянутые выше для создания понятного письма о результатах сборки.
  • Notify Stash Instance, - важный шаг, который извещает Bitbucket (в названии плагина только Stash, да) о результате сборки. Здесь нужно использовать учетную запись , которой разрешен вход в Bitbucket, например, builder. Также передается переменная ${PULL_REQUEST_FROM_HASH}, обозначающая, к какому коммиту относится данный билд.

Пример настройки рабочего билда в скриншоте:

Настройка сборки в Bitbucket

• Необходимо разрешить аутентификацию пользователю builder (в Crowd).
• Для выбранного репозитория/проекта необходимо:
  • добавить access key для пользователя builder.
  • настроить раздел Pull Request, где указать условия возможности Merge. Сейчас условия это: не менее 1 ревьюира и не менее 1 успешного билда.
• Добавить новый триггер (Notification) в Administration → Manage Addons → pull-request-notifier-for-Bitbucket → Configure:
• Buttons - в данный момент добавление кнопки для запуска триггера не требуется.
• Notifications. Необходимо вписать правильный URL для триггера Jenkins (здесь пригодится токен). Чаще всего, это http://<JENKINS>/job/<Job_Name>/buildWithParameters?token=<TOKEN>&${EVERYTHING_URL}. Также в запросе передается переменная ${EVERYTHING_URL}, - это массив переменных, среди которых есть упомянутые выше переменные, используемые в билде. Также стоит обратить внимание на события, по которым происходит срабатывание триггера. Сейчас это происходит при открытии (OPENED), обновлении (UPDATED), открытии заново (REOPENED) пулл реквеста.

Пример настройки триггера приведен на скриншоте:

---

Теперь при создании пулл реквеста будет происходит его сборка в Jenkins, результат сборки отображается в Bitbucket рядом с пулл реквестом или его коммитом, например в случае успешного мерджа:

На почту будут приходить уведомления вида: