Skip to content

Jenkins

andyceo edited this page Jul 18, 2018 · 14 revisions

Установка Jenkins из официального Docker-образа

sudo docker run -d --name jenkins \
    --restart always
    -p 8080:8080 -p 50000:50000 \
    -v /data/jenkins:/var/jenkins_home \
    --env JAVA_OPTS=-Dhudson.footerURL=http://jenkins.example.com-Djava.awt.headless=true -Dhudson.security.csrf.requestfield=crumb \
    jenkins/jenkins:lts-alpine

Не забудьте пробросить проксирующий nginx на порт 8080. Также, имейте в виду, что порт 50000 нужен для подключения дополнительных сборщиков через JLPN (Java Web Start). Если вы будете подключать их через SSH Slaves, то пробрасывать этот порт не нужно.

Также имейте в виду (особенно если вы используете образ на основе Alpine), что переменная JAVA_OPTS может называться по-другому в разных дистрибутивах Linux (JENKINS_JAVA_OPTIONS, например), а также JAVA_OPTS и JENKINS_JAVA_OPTIONS могут использоваться совместно, для разных настроек. Например для jenkins/jenkins:lts-alpine:

JAVA_OPTS: -Dhudson.footerURL=https://jenkins.example.com -Dorg.apache.commons.jelly.tags.fmt.timeZone=Europe/Moscow
JENKINS_JAVA_OPTIONS: -Djava.awt.headless=true -Dhudson.security.csrf.requestfield=crumb -Xms128m -Xmx512m

См. также How to add Java arguments to Jenkins?

В первый запуск, Jenkins создаст админ-пользователя (по умолчанию admin). Jenkins создаст файл с паролем в своей директории $JENKINS_HOME/secrets/initialAdminPassword.

Перезапуск Jenkins

  • (jenkins_url)/safeRestart - Завершает запущенные задачи. Новые задачи ставит в очередь и выполнит после перезагрузки.
  • (jenkins_url)/restart - Рестартует, не ожидая завершения задач.

Включение авторизации по LDAP

@todo

Настройка SSH-slaves в виде контейнеров

Нужно поднять контейнер, который может собирать проект. В качестве примера см. andyceo/phpdevenv - контейнер эмулирует виртуалку на Ubuntu.

Затем надо поставить плагин SSH Slaves.

Затем, добавить новую ноду, в свойствах ноды выбрать Launch slave agents via SSH (jenkins-slave) в список нод Jenkins (нода, на котором выполняется сам Дженкинс, называется master): см. Distributed builds SSH-ключ можно не копировать, если используешь логин-пароль, но можно создать SSH-ключ для пользователя Jenkins (ssh-keygen) (в случае, если Jenkins крутится внутри контейнера, нужно зайти внутрь контейнера с помощью docker exec), затем скопировать его на slave-ноды (ssh-copy-id), и при задании новой ноды, указывать:

  • Launch slave agents via SSH
  • Host: your_host
  • Credentials - выберите уже существующий или создайте новый credential, указав логин (на удаленной машине) и откуда читать приватный ключ чтобы залогиниться
  • Host Key Verification Strategy: Non verifying Verification Strategy - означает что SSH-отпечаток slave-ноды проверяться не будет. Если используем контейнеры в качестве сборочной ноды, то при использовании новой версии образа ключ будет заменен и проверку не пройдет, если она будет. Поэтому выбирайте подходящий вам вариант для каждой из slave-нод.

Остальные параметры выберите по своему усмотрению.

Дергаем задачу (она же билд, таск, джоб) удаленно

Чтобы дернуть удаленно, понадобиться сделать POST-запрос с помощью CURL с токеном конкретного пользователя, т.е. задача будет выполняться из-под этого пользователя.

  1. Note your user API Token (from /user/USER/configure).

  2. Get your crumb:

    Предварительно объявим переменные:

     $USER=root
     $APITOKEN=abcdefg
     SERVER=jenkins.example.com
    

    Запросим crumb так:

     CRUMB=$(curl --user $USER:$APITOKEN http://$SERVER/crumbIssuer/api/xml?xpath=concat\(//crumbRequestField,%22:%22,//crumb\))
    

    Или так:

     curl -s 'http://$USER:$APITOKEN@$SERVER/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)'
    

    этот crumb - будет статичным, его можно передавать, чтобы дергать другие задачи

     curl -v --data "token=citilink.ru&GIT_TAG=v3.21.0" -H crumb:441fd843209bb0e6902ddb678171bc3e --user $USER:$APITOKEN http://$SERVER/job/myjob/buildWithParameters
    

    или:

     curl -X POST -H crumb:441fd843209bb0e6902ddb678171bc3e --user $USER:$APITOKEN http://$SERVER/job/myjob/buildWithParameters?token=citilink.ru&GIT_TAG=v3.21.0
    

См.

Нвстраиваем задачу чтобы она дергалась только по тегу

  • Репозиторий: Git
  • Refspec: +refs/tags/:refs/remotes/origin/tags/
  • Branches to build: origin/tags/*

Передаем переменные из вышестоящей (upstream) сборки в нижестоящую (downstream)

Для этого нижестоящая сборка должна быть настроена как сборка с параметрами.

  1. В нижестоящей сборке добавить параметры сборки (Build parameters)
  2. В вышестоящей сборке добавить послесборочную операцию (post build action) Trigger parameterized build on other projects
  3. В вышестоящей сборке в этой послесборочной операции добавить параметры Add Parameters, выбрать Predefined Parameters и в поле настроить отображение переменных из вышестоящей сборки в нижестоящую, например: PARENT_JOB_NAME=${JOB_NAME}. Можно также просто передать в нижестоящую сборку все параметры, выбрав Current Build parameters
  4. В нижестоящей сборке можно теперь обращаться к параметрам, заданным из вышестоящей сборки как к обычным переменным.

Если нужно чтобы задача запускала процесс, котрый жил бы после сборки (демон)

Вкратце - нужно запускать процесс, указав переменную окружения BUILD_ID=dontKillMe.

GitHub + Jenkins

  • Ставим GitHub Plugin
  • Заходим на страницу настройки Jenkins /configure, листаем до Github Plugin
  • Заходим в свой Github-аккаунт, и создаем там персональный токен для Jenkins с теми разрешениями, что указаны на странице настройки Github-плагина
  • Прописываем в настройки Github plugin нужные параметры доступа (credentials), в котором есть вышесозданный токен. Теперь Github Plugin может сам прописывать необходимые вебхуки в ваши репозитории на GitHub, а также отправлять сообщения о статусах сборок к коммитам репозиториев
  • Добавляем задачу (сборку). В ней указываем что она:
    • GitHub project (указываем URL на GitHub)
    • Управление исходным кодом: Git, а также очищаем поле Branch Specifier (blank for 'any'), чтобы собирались все ветки
    • Триггеры сборки: GitHub hook trigger for GITScm polling (если вы сделали предыдущие шаги с токеном GitHub, то вебхук в репозиторий Jenkins добавит сам)
    • Сборка - добавляем те шаги, что требуются
    • Послесборочные операции: выбираем Set Github commit status (universal) и оставляем все по умолчанию, кроме секции What: - Там ищем Status result и проставляем сначала SUCCESS, затем FAILURE или что-то что требуется. Первый найденный статус будет отправлен на GitHub
    • Сохраняем и наслаждаемся автосборками и автоматическими репортами на GitHub!

Создавать и добавлять SSH-ключ для пользователя Jenkins (из-под которого работает сам Jenkins), не обязательно, если ваши репозитории общедоступны, с ними можно работать по HTTPS.

Также не имеет большого смысла создавать отдельного пользователя на GitHub (например devops), из-под которого потом делать персональный токен для Jenkins. Этому пользователю придется добавить те же права доступа, что и владельцу репозиториев, чтобы создать полнофункциональный токен для Jenkins.

Список плагинов Jenkins

Полезные общие плагины для любых проектов (musthave)

  • GitHub Authentication: позволяет организовать доступ к Jenkins через GitHub OAuth. Лучше сразу использовать Github Committer Authorization Strategy и сразу вписывать логины админов
  • Green Balls: заменяет голубые шарики, сигнализирующие об успешных сборках, на зеленые
  • AnsiColor: плагин добавляет поддержку escape-последовательностей, включая цветовые, в вывод консоли (Console Output)
  • timestamper: добавляет вывод времени в вывод консоли (Console Output) при сборке
  • SSH Slaves: позволяет запускать сборки на удаленных машинах по SSH
  • Git Parameter Plugin: позволяет добавить git тег или sha1 ревизии как параметер в сборки с параметрами
  • Bitbucket: интеграция с Bitbucket. Возможно этот плагин лучше: Bitbucket Branch Source, с ним также интегрируются полезные плагины Bitbucket Aged References SCM Filter Plugin, Bitbucket Branch Source Plugin configuration, Bitbucket Jira Validator SCM Filter Plugin, Bitbucket Commit Skip SCM Behaviour
  • Node and Label parameter: предоставляет и позволяет задать параметры NODE и LABEL для параметризованных сборок (т.е. сборок с параметрами), в основном применяется, чтобы собирать задачу на нескольких сборочных slave-нодах, и можно указать, на каких именно (указать либо тэг, которыми помечены сборочные ноды - LABEL, либо сами ноды непосредственно - NODE)
  • Parameterized Trigger: позволяет вызвать другую сборку по окончании текущей, и передать параметры из сборки в последующую (downstream) сборку. Для того, чтобы передача параметров работала, нужно, чтобы нижестоящая сборка была "Сборкой с параметрами". Чтобы задать переменные в последующую сборку, используйте Predefined Parameters
  • Copy Artifact - копирует артефакты и просто файлы из директории сборки проекта в другой проект. В задаче, из которой артефакты копируются, надо настроить параметр Permission to Copy Artifact - он должен быть включен, а в выпадающем поле должны быть либо перечислены все задачи, которые будут копировать из этой задачи артефакты, либо поле должно быть пустым (всем задачам разрешено копировать артефакты из данной задачи). Можно вообще не задавать этот параметр, но это зависит от прав на задачу, кто может ее/ее артефакты смотреть, доступна ли она для анонимов. В задаче, которая будет копировать артефакты, в разделе "Сборка" нужно создать шаг сборки Copy artifacts from another project и указать необходимые поля. Для копирования файлов из workspace нужно для поля Which build выбрать Copy from WORKSPACE of latest completed build. В поле Artifacts to copy нужно настроить путь до файла(ов), можно использовать маски *.
  • Conditional BuildStep - позволяет создать шаг сборки, который будет выполнен при каких-либо условиях, в качестве условий, можно задать shell-скрипт.

Остальные плагины

  • InfluxDB: позволяет отсылать метрики Jenkins о сборках в InfluxDB-базу. Нестабильный плагин, требует включения необязательных плагинов, а без них падает с ошибкой. Судя по всему, годен только для Java-based проектов с включенными тестами JUnit и подобными
  • FindBugs: для Java-проектов - позволяет построить график stability, в зависимости от отчетов утилиты findbugs. Требуется настроить шаг после сборки и указать в нем где лежит файл отчета в формате xml, образовавшийся на шагах сборки.
  • Static Analysis Collector: агрегирует данные многих утилит статического анализа кода наподобие findbugs.
  • Purge Build Queue - предоставляет ссылку для удаления всех сборок в очереди сборок конкретной задачи (т.е. надо зайти на страницу конкретной задачи)

Работа с артефактами Jenkins

Sidebar is under construction

Clone this wiki locally