Существуют различные способы запуска задания Jenkins из SCM, такого как Bitbucket, но я хочу конкретно запустить сборку с использованием ветки, которая является источником запроса на слияние.
До сих пор мы использовали Bitbucket Pull Request Builder, но он очень нестабилен, ненадежен и плохо поддерживается.
https://wiki.jenkins-ci.org/display/JENKINS/Bitbucket+pullrequest+builder+plugin
Bitbucket действительно предоставляет неплохие функции с точки зрения Webhooks, которые при использовании с Jenkins Git Plugin позволяют запускать сборки на основе различных событий Bitbucket (например, обновления Pull Request).
Существует также плагин Bitbucket Webhook, но опять же, он не предлагает многого с точки зрения динамического выбора ветки, которую вы хотите создать.
https://wiki.jenkins-ci.org/display/JENKINS/BitBucket+Plugin
Однако, похоже, это вызывает опрос репо, где затем пытается построить любую ветвь, отличную от основной.
Наш вариант использования состоит в том, что мы разрешаем разработчикам создавать свои собственные ветви, для которых они затем создают запросы на включение в ветку разработки.
Кажется, нет никакого способа запустить сборку, которая использует ветвь, созданную разработчиком, в качестве ветки сборки (кроме вышеупомянутого Bitbucket Pull Request Builder).
Прав я в этом или нет?
Я реализовал такое решение в компании клиента и считаю, что плагин запроса на вытягивание BitBucket великолепен и отвечает большинству требований.
Вы правы, плагин BitBucket pull request - ваш лучший шанс, иначе вам может потребоваться разработать плагин, но я действительно не думаю, что вы должны, поскольку плагин позволяет вам все, о чем вы можете думать.
В вашем случае вы можете настроить плагин для создания только определенных веток или всех ветвей.
Предположим, разработчик проверяет новую ветку из ветки разработки, затем он разрабатывает и отправляет фиксацию, задание Jenkins, которое настроено как конвейер с несколькими репозиториями и несколькими ветвями, сканирует команду BitBucket, например, каждые 10 минут, и когда оно определяет это добавлен новый код, он автоматически создает новое задание для запроса на вытягивание и новое задание для ветви.
Когда задание запроса на вытягивание завершается, оно уведомляет BitBucket о состоянии сборки (успех, сбой), а затем проверяющий видит зеленую отметку в Confluence, что означает, что задание было выполнено правильно с новым кодом, затем он просматривает код - это дает ему два фактора: первый заключается в том, что код хорошо сочетается с кодом в ветке разработки, а второй фактор - это его собственная проверка кода, если он одобряет код, то новый код объединяется в разработку, запрос на вытягивание автоматически закрывается (или нет - это настраивается в плагине), и в следующий раз, когда запускается сканирование, оно определяет запуск разработки и запускает новый запуск.
Если вы посмотрите на конфигурацию плагина, вы можете настроить, какие репозитории в команде и какие ветки в каждом репозитории должны создаваться автоматически.
Вы можете проверить конвейер, который я написал для этого клиента, в моя учетная запись Github.
Надеюсь, мой ответ вам помог.
Мы создаем задание jenkins для каждого разработчика, а затем используем параметризованную сборку Jenkins, вы просто вводите имя ветки и нажимаете build. Я знаю, что это не полностью автоматизировано, но работает достаточно хорошо. Затем вы можете использовать плагин уведомлений Stash, чтобы сообщить Bit Bucket, что сборка хороша - вы получите красивую зеленую галочку в Bit Bucket.