Как подключить jenkins к bitbucket

Jenkins. Сборка проекта по коммиту в Bitbucket

В прошлом посте я рассказывал о том, как установить Jenkins на сервер под управлением Linux-дистрибутива семейства Debian. В этом же я кратко расскажу о том, как научить Jenkins запускать сборку по коммиту (push’у коммитов) в ветку репозитория Bitbucket.

Подобная связка осуществляется в два этапа: сначала мы настраиваем в параметрах задания удалённый триггер, а потом в параметрах репозитория устанавливаем хук.

Настройка задания в Jenkins

Переходим на страницу нашего проекта и выбираем в панели «Configure». Здесь, в разделе «Build Triggers» нам нужно разрешить удалённый вызов сборки путём включения галки «Trigger builds remotely (e.g., from scripts)» и установки токена. Токен нужен для того, чтобы только вы могли запустить сборку проекта, а у злоумышленников или ботов, проверяющих адреса не было возможности устроить вам DoS. Его можно сгенерировать или придумать. Главное, чтобы он был достаточной длины, чтобы исключить случайность или перебор. Записывать его не обязательно, так как он всегда будет доступен в настройках задания в открытом виде.

Настройка хука в Bitbucket

Зайдём в настройки репозитория и выберем раздел «Hooks», а затем создадим новый хук типа «Jenkins». Перед нами предстанет «окошко», в котором будет необходимо ввести следующие данные:

Описание настроек указанных выше на английском можно найти здесь.

Теперь можно сохранять хук и тестировать связку в деле.

Альтернативы

Опрос репозитория

Одним из вариантов на замену может служить опция «Poll SCM» в разделе «Build Triggers» задания Jenkins. Однако такой способ работает с помощью CRON и выполняет избыточную работу в сравнении с описанным выше методом.

BitBucket Plugin

Кроме того, можно найти плагин, который позволяет задавать произвольные хуки с POST-запросами на Bitbucket. Его минус в том, что он не использует токен и, в случае открытого доступа к системе может позволить вызывать сборку независимо от событий репозитория. Хотя, в обратном случае он может помочь обеспечить несколько большую гибкость.

Заключение

Вот таким, довольно простым способом можно настроить автоматическую сборку проекта в Jenkins по коммиту в Bitbucket. Важно понимать, что механизм удалённых триггеров универсален и вы без особого труда сможете настроить аналогичные действия по коммиту на Github или же вовсе вызывать сборку собственным скриптом из своего репозитория или рабочей машины.

Источник

OpenShift + Jenkins + Bitbucket, непрерывная интеграция и публикация из коробки

В этой статье я покажу, как быстро развернуть среду для сборки, тестирования и публикации приложений используя платформу OpenShift на примере PHP проекта. Использовать буду OpenShift online, но всё это же можно развернуть и на собственных серверах или в VirtualBox (есть готовая сборка). Git-сервером для хранения и версионирования кода будет Bitbucket.

После успешной регистрации в системе, бесплатный аккаунт получает место на серверах и возможность создавать до трёх контейнеров, работающих в связке. А также доменные имена в домене rhcloud.com, вида application-username.rhcloud.com. Этого вполне достаточно для тестирования и экспериментов. Хоть я и разворачивал PHP-контейнер, но OpenShift позволяет таким-же образом развернуть множество других приложений и фреймворков. И ничего не мешает вместо Bitbucket-а использовать GitHub или любую другую систему контроля версий. Внутри облака крутятся docker контейнера, доступ к которым можно получить используя OpenShift Client Tools, но для базовых настроек вполне достаточно и веб-интерфейса.

В OpenShift-е создаём контейнер нужного типа приложения, в нашем случае PHP 5.4. Странно, что староват, при развёртывании нового OpenShift-а на своих серверах гораздо свежее версии и больше вариантов.

Имя у него будет php – оно определит URL контейнера и названия зависимых настроек.

В свойствах контейнера включаем интеграцию с Дженкинсом.

Интеграция создаст в Дженкинсе задачу php-build с необходимыми настройками, которую дальше и будем настраивать. На мастер-ноде по умолчанию сборки отключены (количество сборщиков = 0), в принципе, можно это исправить, но вот публиковать приложение она не будет – не хватает утилит в базовом контейнере. Вполне возможно, это можно исправить покопавшись в контейнере руками (и головой).

Идём в настройки задачи php-build в Дженкинсе. Она уже настроена под сборку на контейнере-сборщике и публикацию в контейнер php, но нам нужно подключить bitbucket. По умолчанию подключается git в контейнере и, в принципе, можно работать и с ним.

Где указываются параметры авторизации bitbucket-а.

Дженкинс умеет работать и по ssh ключам, но тут мешают ограничения контейнера OpenShift, и не удаётся сохранить ключи и разрешение на доступ к хосту bitbucket-а. Возможно, проблему можно надёжно решить поковыряв внутри контейнера jenkins.

Ниже, в поле «Branches to build», указывается ветка, которая будет собираться. Имеет смысл указать явно мастера (*/master).

В полях «триггеры сборки» включаем опции по которым проект будет собираться автоматически. Можно это сделать по webhook-ам; совместно с другими проектами; периодически опрашивать git на предмет изменений и, если они есть, собирать; или просто по расписанию.

В данном случае включены две опции и, кроме webhook-а, будет производиться проверка обновлений каждые 10 минут.

В настройках Сборка → выполнить команду shell уже заполнен шаблон сборки, проверки и публикации проекта в контейнер php.

После комментария « # Run tests here » надо вставить какой-либо код проверки сборки, по результатам которого, либо идём дальше и публикуем, либо выводим ошибку и выходим.

Все операции производятся в контейнере–сборщике в его окружении и его утилитами. Это может наложить ограничения на возможности. Вообще, при разворачивании собственного сервера Jenkins-а, возможностей и контроля больше. А для интеграции с OpenShift можно использовать утилиты rhc и соответствующие плагины Дженкинса (хозяйке на заметку).

Сохраняем, и можно запускать сборку. При этом Дженкинс инициирует создание контейнера-сборщика в облаке OpenShift с именем phpbldr, на который настроена задача. Тут есть нюанс: контейнер поднимается довольно долго и, иногда, задача сборки снимается не дождавшись сборщика. Но, если запустить сборку ещё раз, то на готовом сборщике всё сразу пойдёт. В свойствах проекта есть параметр «Builder Timeout», но он про доменные имена, а не про это. Есть параметры для задержки сборки и количество попыток, но они тоже не помогают.

В системных настройках Дженкинса можно увеличить время жизни сборщика (по умолчанию 15 минут):

Максимальное ограничение в 60 минут прибито гвоздями. Обязательно, что-бы в облаке, на момент сборки, был свободный слот под новый контейнер.

Для настройки сборки по webhook-ам, нужно в свойстве проекта в bitbucket-е включить:
Settings → webhooks → add webhook и указать URL Jenkins-контейнера в виде:

В итоге мы получили свой лунопарк для тестирования и публикации проектов. А если всё это развернуть на своих мощностях, то он ещё и без ограничений да с дополнениями.

Источник

Настраиваем Continuous Integration для Jenkins и Bitbucket с werf

Утилита werf создана так, чтобы её было легко интегрировать с любыми CI/CD-системами. Подробнее об этом процессе в общем случае читайте в эпилоге этой статьи, но основное её содержимое — практический пример по организации CI в Jenkins и Bitbucket.

Подразумевается, что в результате наших действий мы ожидаем получить следующее:

Конфигурация Jenkins

Для реализации задуманного в статье будут задействованы:

Итак, подключаем: Manage Jenkins → Configure System → Global Pipeline Libraries.

Нужно указать имя, ветвь репозитория, из которой Jenkins будет забирать код библиотеки, а в Source Code Management указать адрес и доступ до репозитория (в нашем случае — SSH-ключ для доступа ReadOnly).

Структура Shared Library

Теперь приступим к описанию самой библиотеки. Структура очень проста и состоит всего из трёх директорий:

К тому же, хотелось бы, чтобы весь пайплайн был полностью описан внутри библиотеки, а в Jenkinsfile мы передавали только некоторые параметры деплоя, которые в 99,9% случаев вообще не будут меняться.

Реализуем методы

Итак, реализуем 2 метода.

Триггеры по коммитам из Bitbucket

По умолчанию Jenkins сам не умеет интегрироваться в Bitbucket. Для этого нужно установить уже упомянутые плагины:

Также требуется создать служебного пользователя с доступом к репозиториям, т.к. Jenkins будет обнаруживать весь репозиторий через API. Это касается настройки как для cloud-версии, так и для собственного Bitbucket-сервера.

Пример из глобальных настроек Jenkins:

Далее понадобится настроить source в Multibranch Pipeline, что происходит в интерактивном режиме. Это означает, что, когда вы добавите credentials (Bitbucket пользователя и имя команды или пользователя, с проектами которых мы будем работать), Jenkins найдет все доступные пользователю репозитории и позволит выбрать один из списка.

В самом репозитории мы полагались на поиск только определенных веток, т.к. не уверены, как много веток может быть, а Jenkins может надолго «задуматься», если начнет исследовать каждую ветку. Это накладывает определенные ограничения, т.к. теги тоже попадают под регулярное выражение. Однако Java Regular Expressions — довольно гибкие, так что большой проблемы нет.

Альтернативный путь: если есть желание совсем отделить теги от веток, можно добавить еще один абсолютно такой же Source в репозиторий и настроить его только на обнаружение тегов.

После этого Jenkins с помощью сервис-аккаунта сам сходит в Bitbucket и создаст webhook:

Теперь при каждом коммите Bitbucket будет триггерить пайплайны (но только для тех веток и тегов, что мы отфильтровали) и даже посылать статус пайплайна обратно в Bitbucket в последнем столбце коммита:

Статусы — кликабельные: при нажатии перекидывают в нужный пайплайн в Jenkins

Последний штрих — про Jenkins, который находится за nginx proxy и работает с определенного location. Тогда нужно в основных настройках исправить его location, чтобы он сам знал, как выглядит его endpoint:

Без этого ссылки на pipeline в Bitbucket будут генерироваться некорректно.

Заключение

В статье рассмотрен вариант настройки CI с использованием Jenkins, Bitbucket и werf. Это очень общий пример, который не является панацеей для организации процесса разработки, однако даёт представление о том, как вообще подойти к построению своего CI с использованием werf.

Важная деталь: даже учитывая, что статус пайплайна отдается в Bitbucket, нам всё равно приходится «ходить» в Jenkins, чтобы разобрать результат в случае неудачи. Выкат по тегу через webhook, очевидно, может отрабатывать только один раз: любой откат на предыдущий тег придется делать вручную из Jenkins.

У данного подхода также есть большой плюс — это гибкость. Мы буквально можем прописать в CI всё что угодно. Хотя и порог вхождения для того, чтобы понимать, как именно это сделать, чуть выше, чем у других CI-систем.

Эпилог: про werf и CI/CD в целом

Общий подход к интеграции werf с CI/CD-системами описан в документации. Вкратце рекомендуемые для любых проектов шаги сводятся к следующим:

Источник

Bitbucket Server Integration

We’re collecting feedback at issues.jenkins-ci.org. Head there to see what issues have been created, or create a new issue using the component atlassian-bitbucket-server-integration-plugin.

The Bitbucket Server integration plugin is the easiest way to connect Jenkins to Bitbucket Server. With a few simple steps you can configure it to:

The plugin streamlines the entire configuration process and removes the need for multiple plugins to achieve the same workflow.

Plugin features

Requirements

Note: Bitbucket Server 5.6 to 7.3 are also supported, but they’re not recommended. This is because some plugin features are not available when using these versions. Instead, we recommend using Bitbucket Server 7.4+. With 7.0+ you can make use of pull request triggers for jobs. With 7.4+ you can set up an Application Link to have access to all plugin features.

In this document

Install the plugin

To install the plugin:

The status will change to Success when the plugin is installed.

Configure the plugin

To configure the plugin:

Add Bitbucket Server instance details

Bitbucket Server instances are added and configured at the system level. Once they’re added users can select them from the SCM when creating a Jenkins job. You must add at least one Bitbucket Server instance to Jenkins.

When adding a Bitbucket Server instance you must add at least one Bitbucket Server personal access token that is configured with project admin permissions. Doing this allows users to automatically set up build triggers when creating a Jenkins job.

Watch our video to find out how to do this, or see below for written instructions.

To add a Bitbucket Server instance:

Create an Application Link

Creating an Application Link to Jenkins enables additional functionality in Bitbucket Server. Watch our video to find out how to do this, or see below for written instructions. This step is only relevant if you’re on Bitbucket 7.4+.

1. Register Bitbucket Server as a consumer

There are two parts to creating an Application Link. The first is done in Jenkins and involves registering Bitbucket Server as a consumer.

To register a consumer:

After you save, you’ll be taken to a page called Application Link details. It’s a good idea to keep this page open when moving onto part 2 so you can copy the details across to Bitbucket Server.

You can also access the Application Link details page by going to Jenkins > Manage Jenkins > Manage Bitbucket Server consumers, and selecting the Application Link details for the consumer.

2. Create an Application Link to Jenkins

The second part is done in Bitbucket Server and involves creating an Application Link to Jenkins. Many of the details you need to do this are on the Application Link details page mentioned in step 1.

To create the Application Link:

After a moment, your Jenkins instance will appear in the list of linked applications.

Use the plugin

Select a Bitbucket Server instance when creating a Freestyle Job

Once you’ve added a Bitbucket Server instance to Jenkins, users will be able to select it when creating a job. This will make it easier for them to select the repo to be cloned. They’ll also be able to select the Bitbucket Server build trigger to automatically create a webhook.

To select a Bitbucket Server instance when creating a Freestyle job:

Note: A Jenkinsfile is required when creating a Pipeline or Multibranch Pipeline job. Other pipeline scripting methods are not yet supported.

Create a Multibranch Pipeline

To use a different Jenkinsfile for different branches of your Bitbucket Server project, you need to create a Multibranch Pipeline and add the Jenkinsfile to the repo of each branch you want to build. Jenkins will then automatically find, manage, and execute these Pipelines.

Watch our video to find out how to do this, or read more about Multibranch Pipelines on Jenkins.io.

Additional documentation

Contribute to the plugin

Plugin development

This plugin uses Apache Maven for development and releases. It also uses Groovy as part of the presentation layer for the plugin. To build Groovy files you need to install the SDK.

Checkstyle

Alternatively, you can link to the pre-commit hook directly:

Building

To build the plugin run:

Running Jenkins with the plugin enabled

Debugging

To start Jenkins (and Maven) in debug mode run:

You can then run Bitbucket Server using AMPS with the following command:

This will start Bitbucket Server on http://localhost:7990/bitbucket.

Running tests

Источник

Космонавт в лодке

Личный блог Олега Абражаева о программировании, технологиях и о жизни

Рубрики

Облако меток

Свежие комментарии

livelib.ru

Подписаться на обновления!

Настройка интеграции jenkins + bitbucket + slack для php проекта

Указанная в заголовке связка незначительно облегчает процесс deploy проекта, т.к. предназначена не совсем для этого. Эта связка скорее для мониторинга и трекинга работы над проектом, а так же минимальный контроль ошибок и качества. Так же в команде, которая использует Slack, удобно видеть когда были изменения от других участников.

Идея конфигурации

В качестве системы контроля версий будет использоваться Mercirial (hg). В проекте обязательно присутствуют 3 ветки – dev, staging, stable. На каждую ветку настроен свой хост на сервере. Это рекомендуемая и проверенная практика деплоя приложения. Наилучшим образом об этом написано тут – http://guides.beanstalkapp.com/deployments/best-practices.html

Основной смысл в том, что в dev деплоятся критические изменения, в staging те, что не меняют значительно проект, относильно stable. Ну а stable это то, чем пользуются пользователи, продакшн. Учитывая эту рекомендацию автодеплой с jenkins стоит настраивать только на staging. Для dev это сделать эффективно не получится, т.к. при критических изменениях по большей части приходится делать все руками. Более того на dev допустимы ошибки, а на staging, в предрелизном состоянии, уже нет.

Настройка Jenkins и ant

Для начала необходимо установить на сервер сам jenkins и ant. Моя версия jekins 2.7. Именно через конфиг ant будут описаны шаги, после выполнения которых можно будет считать, что build прошел успено.

Дальше нужно установить плагины slack, ant и bitbucket. У меня установлены следующие плагины: ant 1.2, bitbucket 1.1.0, cloverphp 0.4, cvs, git 2.3.5, git-client 1.17.1, junit 1.6, maven-plugin 2.10, mercurial 1.54, php 1.0, pmd 3.41, slack 1.8, xunit 1.96
На самом деле список гораздо больше, тут я оставил только актуальные для меня.

Далее для php проекта будет актуальна следующая ссылка с шаблоном – http://jenkins-php.org/.
Конкретно на шаге установки необходимых php инструментов и плагинов для jenkins приводится достаточно большой список. У себя в конфиге ant с названием build.xml я оставил только lint проверку на синтаксические ошибки и чуть позже мне понадобится phpunit, остальное убрано. На самом деле удобнее начинать с минимального конфига и добавлять все потом.

Необходимо установить проект-шаблон в jenkins и как это сделать описано тут. В итоге проект php-template появится на главной странице jenkins.
Теперь на основе этого шаблона можно создать проект в jenkins под свой php проект, путем выбора “copy exiting project” при создании нового проекта и выбора там php-template. После чего зайти в конфигурацию созданного проекта и удалить там лишнее и настроить что нужно.

В глобальной конфигурации jenkins необходимо настроить конфигурации инсталяций для ant и mercurial (или git). Они уже должны быть установлены на сервере и тут необходимо только прописать пути к исполняющимся файлам и домашним директориям. В разделе конфигурации slaсk можно прописать название домена команды (только приставка, без slack.com) и адрес, по которому доступен jenkins на внешку, например ip/8080.

В конфигурации безопасности необходимо во первых включить безопаность, далее поставить галочки на Jenkins’ own user database и Allow users to sign up, и ниже один из вариантов Anyone can do anything или Logged-in users can do anything. Конечно если веб интерфейс доступен на внешку, то подойдет только второй вариант, в случае если он доступен только на разрешенный ip удобнее работать при первом варианте.

Теперь нужно создать пользователя. Его нужно создать в любом случае, т.к. именно api токен этого пользователя будет использовать bitbucket для инициализации билда проекта. Перейдя на вкладку People создать пользователя и нажать Show api token. Можно скопировать заранее куда-то. В моем случае будет такое
user – abrakadabrausertoken

Подготовка проекта в Jenkins

В проекте Jenkins, который создан как копия от шаблона php-template, в настройках нужно сделать следующее:

Источник