Запуск задания Jenkins с помощью Bitbucket Pull Request
Существуют различные способы запуска задания 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
Однако, похоже, это вызывает опрос репо, после чего он пытается построить любую ветку, отличную от основной.
Наше использование c Например, мы разрешаем разработчикам создавать свои собственные ветви, для которых они затем создают запросы на извлечение в ветку разработки.
Кажется, нет никакого способа запустить сборку, которая использует созданную разработчиком ветвь в качестве ветви сборки ( кроме вышеупомянутого Bitbucket Pull Request Builder).
Прав ли я в этом или нет?
Я внедрил такое решение в компании клиента и думаю, что плагин BitBucket для работы с запросами на вытаскивание является отличным решением и отвечает большинству требований.
Вы правы, плагин для работы с запросами на вытаскивание BitBucket - это ваш лучший вариант, в противном случае вам может потребоваться разработать плагин самостоятельно, но я не думаю, что вы должны это делать, так как плагин дает вам все, что вы можете придумать.
В вашем случае, вы можете настроить плагин так, чтобы он создавал только определенные ветки или все ветки.
Допустим, разработчик проверяет новую ветку из ветки разработки, затем он разрабатывает и запускает коммит, работа Jenkins, которая настроена как конвейер с несколькими репозиториями, сканирует, например, команду BitBucket каждые 10 минут, и когда он обнаруживает, что новый код был протолкнут, он автоматически создает новую работу для запроса на вытаскивание и новую работу для ветки.
Когда работа с запросом на вытаскивание заканчивается, он уведомляет BitBucket о статусе сборки (успех, неудача), а затем рецензент видит зелёную метку в Confluence, означающую, что работа закончена правильно с новым кодом, он затем просматривает код - это даёт ему два фактора: Первый - это то, что код хорошо играет с кодом в ветке разработки, а второй - это его собственный обзор кода, если он одобряет код, то новый код сливается с разработкой, запрос на подтягивание автоматически закрывается (или нет - он настраивается в плагине) и при следующем запуске сканирования он идентифицирует подтягивание к разработке и запускает новый запуск.
Если вы посмотрите на конфигурацию плагина, вы можете настроить, какие репозитории в команде и какие ветки в каждом репозитории должны быть построены автоматически.
Вы можете проверить конвейер, который я написал для этого клиента в моей учётной записи Github.
Надеюсь, мой ответ помог вам.
.Мы создаем задание jenkins для каждого разработчика, а затем используем параметризованную сборку Jenkins, вы просто вставляете имя ветки и нажимаете кнопку build. Я знаю, что это не полностью автоматизировано, но работает достаточно хорошо. Затем вы можете использовать плагин уведомления Stash, чтобы сигнализировать Bit Bucket о том, что сборка хороша - вы получаете красивую зеленую галочку в Bit Bucket.
.Мы также столкнулись с этой проблемой и в итоге обнаружили, что Универсальный триггер веб-перехватчика полностью удовлетворяет всем нашим требованиям.
Этот плагин позволяет вам определить триггер на основе веб-перехватчика bitbucket без необходимости определять шаг SCM в вашем задании, а также позволяет легко извлекать любые необходимые параметры из Event Payload, отправленного Bitbucket.
Он имеет отличную поддержку Freestyle Jobs, Pipeline Jobs и Job DSL.
Единственная сложная часть заключается в сопоставлении веб-перехватчиков с заданиями Jenkins, что не выполняется автоматически с использованием URL-адреса репозитория, как другие триггеры, но мы использовали встроенный механизм токенов для управления тем, какие задания инициируются различными веб-перехватчиками репозитория, что дало нам необходимые отображение.
В целом мы пользуемся этим плагином уже несколько месяцев, и он работает отлично.