Вопрос или проблема
Существует множество способов запустить задачу Jenkins из SCM, такого как Bitbucket, но то, что я хочу сделать конкретно, это запустить сборку, используя ветку, которая является источником Pull Request.
До сих пор мы использовали 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 plugin, но опять же он не предлагает многого в плане динамического выбора ветки, которую вы хотите собрать.
https://wiki.jenkins-ci.org/display/JENKINS/BitBucket+Plugin
Однако, похоже, что он запускает опрос репозитория, где затем пытается собрать любую ветку, отличную от основной.
Наш случай использования заключается в том, что мы позволяем разработчикам создавать собственные ветки, для которых они затем создают Pull Requests в ветку разработки.
Не кажется, что есть какой-либо способ запустить сборку, которая использует ветку, созданную разработчиком, в качестве сборочной ветки (кроме вышеупомянутого Bitbucket Pull Request Builder).
Я прав или ошибаюсь в этом?
Мы создаем задание Jenkins для каждого разработчика, а затем используем параметризованную сборку Jenkins, вы просто указываете имя ветки и нажимаете “собрать”. Я знаю, что это не полностью автоматизировано, но это работает достаточно хорошо. Затем вы можете использовать плагин Stash notifier, чтобы сигнализировать обратно в Bitbucket, что сборка прошла успешно – вы получаете приятную зеленую галочку в Bitbucket.
Я реализовал такое решение в компании клиента, и я думаю, что плагин BitBucket pull request отлично работает и отвечает большинству требований.
Вы правы, плагин BitBucket pull request — ваш лучший выбор, иначе вам может понадобиться разработать собственный плагин, но я действительно не думаю, что вы должны это делать, потому что плагин позволяет вам делать все, что только можно придумать.
В вашем случае вы можете настроить плагин так, чтобы он собирал только конкретные ветки или все ветки.
Предположим, разработчик выходит на новую ветку из ветки разработки, затем он разрабатывает и загружает коммит, задача Jenkins, которая настроена как многофайловый репозиторий с многофайловым конвейером, сканирует команду Bitbucket каждые 10 минут, например, и когда она определяет, что был загружен новый код, автоматически создается новая задача для Pull Request и новая задача для ветки.
Когда задача Pull Request завершается, она уведомляет Bitbucket о статусе сборки (успех, неудача), и тогда рецензент видит зеленую отметку в Confluence, что означает, что задача успешно завершилась с новым кодом, затем он проверяет код — это дает ему два фактора: первый — что код хорошо сочетается с кодом в ветке разработки, и второй фактор — это его собственная проверка кода, если он утверждает код, то новый код объединяется в разработку, Pull Request автоматически закрывается (или не закрывается — это настраивается в плагине), и в следующий раз, когда производится сканирование, определяется отправка в разработку и запускается новый запуск.
Если вы посмотрите на конфигурацию плагина, вы можете настроить, какие репозитории в команде и какие ветки в каждом репозитории должны автоматически создаваться.
Вы можете проверить конвейер, который я написал для этого клиента, в моем аккаунте Github.
Надеюсь, мой ответ помог вам.
Мы также столкнулись с этой проблемой, и в итоге обнаружили, что Generic Webhook Trigger полностью удовлетворяет всем нашим потребностям.
Этот плагин позволяет определить триггер на основе битбакет вебхука без необходимости определять шаг SCM в вашей задаче, также он позволяет легко извлечь любые необходимые параметры из Пейлоад события, отправленного Bitbucket.
Он имеет отличную поддержку для Freestyle Jobs, Pipeline Jobs и Job DSL.
Только часть, которая требует некоторой осторожности, — это сопоставление вебхуков с задачами Jenkins, что не выполняется автоматически с использованием URL репозитория, как и другие триггеры, но мы использовали встроенный механизм токенов, чтобы контролировать, какие задачи активируются разными вебхуками репозитория, что дало нам необходимое сопоставление.
В целом мы используем этот плагин уже несколько месяцев, и он работает идеально.
Ответ или решение
Конечно! Давайте подробно рассмотрим вопрос о том, как запускать задачи в Jenkins из Pull Request в Bitbucket и рассмотрим различные подходы и решения для этой задачи.
Теория
Для управления непрерывной интеграцией (CI/CD) в современном мире разработки популярным решением является использование Jenkins совместно с системой контроля версий, такой как Bitbucket. Постановка задачи заключается в автоматическом запуске сборки Jenkins всякий раз, когда разработчик создает или обновляет Pull Request в Bitbucket. Важно обеспечить, чтобы сборка выполнялась на основе исходной ветки Pull Request, а не главной ветки или какой-либо другой.
На первый взгляд, задача кажется тривиальной, но в реальности многие сталкиваются с трудностями при реализации полностью автоматизированного подхода. Основные проблемы, с которыми сталкиваются разработчики, включают в себя необходимость работы с ненадежными плагинами или ограниченными возможностями интеграции в Jenkins с Bitbucket.
Пример
Ранее для решения данной задачи использовался плагин Bitbucket Pull Request Builder. Этот плагин позволял запускать задачи Jenkins, основываясь на обновлениях в Pull Request. Однако его недостатки заключались в нестабильности и недостаточной поддержке. Особенно остро стояла проблема динамического выбора ветки для сборки.
Bitbucket предлагает механизмы Webhooks, которые позволяют отправлять уведомления в Jenkins о различных событиях (например, создание или обновление Pull Request). Эти Webhooks можно использовать совместно с Jenkins Git Plugin, чтобы инициировать сборки. Помимо этого, существуют плагины, такие как Bitbucket Webhook, которые хотя и немного расширяют возможности, но зачастую не позволяют гибко настраивать выбор ветки для сборки.
Другие подходы, которые использовались ранее, включали создание параметризованных задач в Jenkins, где пользователь вручную указывал имя ветки для сборки. Это полуручной процесс, который хотя и работает, но не обеспечивает полную автоматизацию.
Применение
Плагин BitBucket Pull Request Builder и другие подобные инструменты могут быть хорошим решением, если их возможности соответствуют вашим требованиям. Однако если рассматриваемый плагин не решает всех задач, следует искать альтернативные решения. Одним из таких решений является использование Generic Webhook Trigger. Этот плагин позволяет настроить запуск задач Jenkins на базе вебхуков из Bitbucket без привязки к конкретной конфигурации SCM в задаче. Плагин позволяет извлекать параметры из загрузочного пакета событий, присылаемого из Bitbucket, что позволяет более гибко управлять параметрами сборки.
Generic Webhook Trigger обладает отличной поддержкой различных типов задач в Jenkins: Freestyle Jobs, Pipeline Jobs и Job DSL, и подходит для реализации более гибкой и комплексной архитектуры запуска задач.
Также можно использовать мультибренчевые пайплайны Jenkins. Это мощный инструмент, который позволяет Jenkins автоматически обнаруживать новые ветки и создавать на их основе задачи, что может соответствовать требованиям к автоматизации процесса интеграции и тестирования Pull Request.
Заключение
Решение задачи автоматического запуска задач Jenkins при создании или обновлении Pull Request в Bitbucket подразумевает использование различных инструментов и подходов. Если готовые решения, такие как плагин Bitbucket Pull Request Builder, не соответствуют требованиям, имеет смысл рассмотреть использование более комплексных инструментов и плагинов, таких как Generic Webhook Trigger и мультибренчевые пайплайны Jenkins.
Использование этих инструментов обеспечит более высокую степень автоматизации и настройки процесса, что позволит сократить количество ошибок и повысить надежность системы CI/CD. Ключевой момент в реализации такого подхода — это детальное понимание особенностей работы каждого из используемых инструментов и их конфигурации в контексте конкретных требований проекта.
Надеюсь, этот ответ поможет в настройки более стабильного и гибкого процесса интеграции Jenkins с Bitbucket для автоматической обработки Pull Request.