werf+Jenkins

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

Jenkins pipelines: 3 интересных видео

Jenkins Declarative Pipeline vs Scripted Pipeline - 4 key differences
Jenkins Scripted Pipeline vs Declarative - answering viewer's questions!

Jenkins Pipeline Environment Variables explained

Jenkins: пропускаем шаг начальной настройки

При автоматической выкатке часто надо пропустить шаг настройки (мастер), есть несколько способов
1) java  -Djenkins.install.runSetupWizard=false -jar jenkins.war
Вариант через переменную (для докера)
ENV JAVA_OPTS "-Djenkins.install.runSetupWizard=false ${JAVA_OPTS:-}"

2) поставить плагин jcasc и при влитом конфиге он должен визард пропускать. Но не всегда, например https://github.com/jenkinsci/configuration-as-code-plugin/issues/393, поэтому 1 метод предпочтительнее.

3) Не проверялось, но иногда встречается в гугле
echo ${JENKINS_VERSION} > ${JENKINS_HOME}/jenkins.install.UpgradeWizard.state

Accessing and dumping Jenkins credentials

https://codurance.com/2019/05/30/accessing-and-dumping-jenkins-credentials/

Jenkins pipeline jobs

Помимо Freestyle задач, если pipeline, это код на груви. Главные преимущества - переносимость, возможность держать конфиги в системе контроля версий, сами pipelines можно прямо из гита вызывать, можно код положить в Jenkinsfile и передавать вместе с проектом.
Минусы - сложность освоения, зачастую совершенно невнятные ошибки, что раньше в вебе накликивалось за пол часа, теперь надо долго и вдумчиво писать.
Чуть добавляет сложности то, их несколько видов, и они не очень совместимы.
По синтаксису: scripted, declarative
Pipeline, multibranch pipeline

Intro
https://jenkins.io/doc/book/pipeline/getting-started/
https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md

Next
https://jenkins.io/doc/book/pipeline/syntax/

2 models
https://jenkins.io/doc/pipeline/steps/pipeline-model-definition/

For plugins
https://jenkins.io/doc/pipeline/steps/

Очень достойные документы, где описано очень много полезного. post, when... Хотя бы по диагонали но прочитать.
https://www.blazemeter.com/blog/how-to-use-the-jenkins-scripted-pipeline/
https://www.blazemeter.com/blog/how-to-use-the-jenkins-declarative-pipeline/

Advanced:
https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin

PS
Раньше формат вызова плагинов был примерно таким
step([$class: 'ArtifactArchiver', artifacts: 'something'])
В новом синтаксисе (года с 2016) это гораздо читаемее и сокращается до
archiveArtifacts 'something'
Но. Не всегда. Например, в 2020 у плагина Mailer существует только такой формат вызова
step([$class: 'Mailer']): E-mail Notification
https://jenkins.io/doc/pipeline/steps/mailer/

Чуть больше про это
https://stackoverflow.com/questions/48797509/class-syntax-in-jenkins-scripted-dsl

PS2
When a recorder is run from a pipeline, it might set the build’s status (for example to unstable), but otherwise is likely to work intuitively. Running a notifier is trickier since normally a pipeline in progress has no status yet, unlike a freestyle project whose status is determined before the notifier is called. To help interoperate better with these, you can use the catchError step, or manually set a build status using currentBuild.result. See the help for the catchError step for examples.

https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/workflow/steps/CatchErrorStep/help.html
catchError : This step is most useful when used in Declarative Pipeline or with the options to set the stage result or ignore build interruptions. Otherwise, consider using plain try-catch-finallyblocks.

Jenkins: передача параметров между задачами

Иногда (часто) есть несколько задач, между которыми надо передавать аргументы.
В случае, если первая задача хочет запустить вторую, тут очень просто. Ставим плагин Parameterized Trigger plugin, во второй задаче перечисляем что мы хотим получать, а в первой добавляем шаг сборки "Trigger/Call builds on other projects" и там есть поле для переменных, которые мы передаём, формат обычный, NEW_VAR=some_var
как-то так
А вот от второй задачи к первой - весьма сложно. Пожалуй, самым простым вариантом - во второй задаче выводим нужные переменные в файл, а в первой импортируем переменные из файла, через шаг сборки Inject environment variables. То есть через trigger build запускаем вторую задачу, там внутри пишем нужные переменные в общедоступный файл (поэтому будет работать только внутри 1 сервера, и папки лучше всего брать $HOME или /tmp), а следущим шагом через inject читаем переменные, формат переменных обычный, на строку VAR="value", сам путь в Properties File Path
примерно так

Jenkins и upload to S3

Жил-был дженкинс, работал себе, задачи на нём вида Freestyle крутились себе. И сразу оговорка, нода, на которой запускалась задача выкатки, не в амазоне, дальше это будет важно.

Есть для выкатки через freestyle плагин s3 publish, он же /s3/ в плагинах. Но есть у него огромный, гигантский косяк: он не умеет в ACL. Вообще не умеет. Ни в каком виде. А на офсайте жалкая отмазка "выставите нужные права на весь бакет через IAM", что разумеется далеко не всегда приемлемо.
Да, у него есть metadata, но толку от неё ровно 0. Потому что оно мало того что не умеет Canned ACL, так даже x-amz- не выставить, там захардкожен префикс, что-то вроде x-amz-meta-, и ничего с этим не сделать. Ладно, не было печали, посмотрим другие варианты.
aws s3 cp|sync
s3cmd put|sync
итд - поскольку нода не в амазоне, мы не можем настроить IAM на выкатку без токена, а по некоторым причинам его могут не давать сделать.
Хорошо, есть вроде неплохой плагин aws pipeline plugin, он умеет сильно больше чем s3 plugin, поставим. И первый косяк, оно не умеет в freestyle. Надо переписывать задачу в pipeline. Что ж, давно было желание, переписали. Второй косяк. s3Upload не работает, потому что конфликт имён с s3 plugin. И как только мы удаляем s3 plugin, у нас ломаются все связанные задачи. А их может быть больше десятка. Но и это не всё. Косяк 3. Похоже, что s3 plugin выкатывал файлы через Jenkins, потому что оно просто работало. А aws pipeline делает это с самой ноды, и ничего не работает. Никто же не добавил AWS_ переменные. Но даже если добавить withAWS - может не заработать, если у нас не 2 переменные а 3: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN. И передать их как-то - не выйдет. И выставить через def в начале пайплайна - тоже не работает. Так что 2 плагина, функционал которых фактически не пересекается, вместе стоять не могут.

Тут на помощь приходят copyArtifact и более удобный в данном случае stash, при условии что у нас есть нода в амазоне, на которой можно будет сделать unstash + s3Upload.

На то, чтобы выяснить и отладить это всё, может уйти не 1 день.
Если бы удалось пропихнуть фикс в s3 plugin с переименованием s3Upload во что-то ещё (в этом модуле всего 2 функции, в отличие от заточенный под пайплайны aws pipeline), то они могли бы существовать мирно вместе. А так - им надо обоим ставить тэг Conflicts и блокировать совместную установку.

Jenkins: write own plugin

https://stackoverflow.com/questions/49815413/jenkins-custom-plugin

Jenkins: переносим задачи на другой сервер

При наличии доступа к серверу:

переносим /var/lib/jenkins

Jenkins plugins: Usage plugin

https://plugins.jenkins.io/plugin-usage-plugin
https://wiki.jenkins.io/pages/viewpage.action?pageId=73532011
Показывает список установленных плагинов, а для классических задач покажет ещё кто использует (но только использует явно, по связанности может показать нули), а по кнопке expand даже покажет, какими задачами какой плагин используется.

Jenkins+aws

Самый простой вариант это ставим aws cli и через execute shell, но далеко не самый правильный

https://github.com/jenkinsci/pipeline-aws-plugin
Умеет работать с s3, cfn, sns и ещё чуть по мелочи

https://jenkins.io/doc/pipeline/steps/s3/
https://plugins.jenkins.io/artifact-manager-s3
более частные случаи

Jenkins: более гибкие возможности с freestyle configuration

При работе с freestyle configuration часто встают вопросы переноса конфигураций, их архивирования, контроле версий и прочем. Они конечно доступны в xml формате, но работа "напрямую" крайне неудобна. Плюс нет механизмов контроля подключённых плагинов, нужно отдельно получать их список с версиями и носить в отдельных файлах. Но если нет возможности перейти на pipeline, есть плагины, облегчающие жизнь.

Jenkins, HTML documentation and security

Jenkins может сам генерировать документацию, но доступ к ней будет ограничен по CSP
Jenkins 1.641 / Jenkins 1.625.3 introduce the Content-Security-Policy header to static files served by Jenkins (specifically DirectoryBrowserSupport). This header is set to a very restrictive default set of permissions to protect Jenkins users from malicious HTML/JS files in workspaces, /userContent, or archived artifacts.

Unfortunately, several popular, useful plugins are affected by this and lose part of their functionality unless the default rules are relaxed.
https://wiki.jenkins.io/display/JENKINS/Configuring+Content+Security+Policy

Сначала для обхода надо было выставлять hudson.model.DirectoryBrowserSupport.CSP, например через консоль
System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' 'unsafe-inline' data:;")

Или через конфиг файлы
https://kb.froglogic.com/squish/integrations/jenkins/content-security-policy-csp-web-report/
https://stackoverflow.com/questions/37618892/jenkins-content-security-policy

Но с версии 2.200 введено улучшение - отдельный путь для документации, зовётся Resource root URL. По встроенной справке много подробностей.

https://issues.jenkins-ci.org/browse/JENKINS-41891

Jenkins, freestyle job and git commit

Если требуется внести какие-либо изменения в гит ветку через jenkins, у нас есть плагин Git Plugin. Но он хорошо работает только если нам не нужны правки в репе, потому что суть плагина в том что он делает "detached HEAD", через получение id последнего коммита в ветке и git checkout (id), получая тем самым этот detached.
При этом мы можем сделать в сборке коммит (но не можем push - запросит данные для авторизации в гите), а дальше в послесборочных операциях добавляем Git Publisher, который вроде как пушит.. но всё пропадает бесследно. Также проблем добавляет то, что описания (те что в дженкинсе по нажатию вопроса) писал имбецил, из них непонятно ничего. Прежде всего речь про git publisher - branches.
Рекомендуется в Additional Behaviours добавить Clean before checkout
И до начала убеждаемся, что у нас есть права на push, иначе можно очень долго тупить когда будет говорить repository not found.

Что нужно проверить.
В управлении исходным кодом стоит refs/heads/our_branch
В Additional Behaviours добавлено
1) Clean before checkout
2) Custom user name/e-mail address и заполнено
3) Check out to specific local branch - commitbranch (имя можно поставить своё, это временная ветка, если первый пункт не ставить то в имя добавить $BRANCH_ID)
Таким образом, detached HEAD у нас превращается в локальную ветку, с которой гораздо проще работать.

Для успешного пуша необходимо в Branches - add branch добавить ветку,
Branch to push - имя ветки куда мы будем пушить, без префиксов, если пушить надо туда же откуда делали чекаут то нужно распарсить $GIT_BRANCH, взяв только последнюю секцию (без origin/ или refs/heads/), например так ${GIT_BRANCH/refs\/heads\//}
Target remote name - origin

Но есть и "другие варианты"
Итак, вариант первый: в build добавляем
git checkout $GIT_BRANCH и будет нормальный чекаут
https://stackoverflow.com/questions/19922435/how-to-push-changes-to-github-after-jenkins-build-completes/29786580
(но с пушем по прежнему есть нюансы, читаем по ссылке)

Вариант второй: сделать временную ветку и потом мержить её в нужную нам
Additional Behaviours - Check out to specific local branch
commitbranch-$BRANCH_ID
по сути, выше это и описано

Вариант третий:
Пушить не через git publisher а из шелла. Привет проблемы с тем как передать авторизацию, надо читать про git_askpass
https://stackoverflow.com/questions/42627269/jenkins-using-git-askpass-to-set-credentials/42636309
и в общем самый костыльный вариант

И ещё можно почитать
https://riptutorial.com/jenkins/example/27915/configuring-the-auto-push-job
https://stackoverflow.com/questions/14766214/jenkins-git-publisher-how-to-push-back-to-git-branch
https://www.theserverside.com/video/Tips-and-tricks-on-how-to-use-Jenkins-Git-Plugin

Полезные модули Jenkins: разрабатываем под Unity3d

https://wiki.jenkins.io/display/JENKINS/Unity3dBuilder+Plugin
По запуску читаем доку.

Также для публикации в google store есть
https://wiki.jenkins.io/display/JENKINS/Google+Play+Android+Publisher+Plugin
Увы, маководы должны страдать и под них плагинов нет. Причём даже fastlane не поможет - это враппер на itms, который нормально работает только под маком.
Хотя есть такое
https://wiki.jenkins.io/display/JENKINS/Xcode+Plugin

Полезные модули Jenkins: Copy Artifact

Когда задачи достаточно сложные, часто они выстраиваются в цепочки. И бывает так, что собриаем артефакт на одном воркере, а потом обрабатываем на другом. Тогда пригодится модуль Copy Artifact.
https://wiki.jenkins.io/display/JENKINS/Copy+Artifact+Plugin
Но с ним есть нюанс: если есть 2 задачи, ставить задачу с copy зависимой может вызвать труднопонимаемые проблемы, в частности режимы что копировать. По сути, в там случае рабочий режим только один - "Upstream build that triggered this job". В случае Latest successful будет вливаться артефакт предыдущего успешного запуска, поскольку к моменту copy он ещё не successful.

Что ещё можно глянуть
https://codurance.com/training/2014/10/03/guide-to-deploying-artifacts-with-jenkins/
https://subscription.packtpub.com/book/networking_and_servers/9781788297943/6/ch06lvl1sec65/copying-an-artifact-from-another-build-job
https://jenkinsci.github.io/job-dsl-plugin/#plugin/copyartifact
http://qaru.site/questions/502425/how-can-i-use-the-jenkins-copy-artifacts-plugin-from-within-the-pipelines-jenkinsfile

Полезные модули Jenkins: Базовые модули

Чтобы передать параметры в сборку
https://wiki.jenkins.io/display/JENKINS/Parameterized+Trigger+Plugin
Передача паролей в сборку
https://wiki.jenkins.io/display/JENKINS/Credentials+Binding+Plugin

Полезные плагины для работы с гитом и гитхабом
https://wiki.jenkins.io/display/JENKINS/Github+Plugin
https://wiki.jenkins.io/display/JENKINS/Git+Plugin
https://wiki.jenkins.io/display/JENKINS/GitHub+Integration+Plugin

Если что-то собираем
https://wiki.jenkins.io/display/JENKINS/Build-timeout+Plugin

Jenkins + Google Play: быстрый старт (очень быстрый)

1) https://wiki.jenkins.io/display/JENKINS/Google+Play+Android+Publisher+Plugin
2) https://www.youtube.com/watch?v=txdPSJF94RM&list=PLhF0STyfNdUk1R3taEmgFR30yzp41yuRK&index=1 и второе видео

Обращаем внимание на grants, иначе при попытке выкатки будет FORBIDDEN без объяснений - это забыли выдать права (grant permissions) по ключу

Если ошибка - APK specifies a version code that has already been used.

то надо смотреть свойства приложения в коде, плагин оттуда выдёргивает CodeVersion. Также можно глянуть https://developer.android.com/google/play/expansion-files.html

Как альтернатива - есть fastlane

Fastlane  -  это инструмент для автоматизации процессов сборки и выкладки мобильных iOS и Android приложений, которая включает в себя также генерирование скриншотов, запуск Unit/UI тестов, отправка сообщений в Slack, подключение к Crashlytics и многие другие полезные вещи, которые упрощают жизнь.

Напримр

Если будет желание ставить fastlane, в центоси руби версии 2.0, а там по зависимостям нужен 2.1+, дока по установке руби 2.1
https://tecadmin.net/install-ruby-latest-stable-centos/
Переключаем руби в 2.1, и далее gem install fastlane -NV

ставим jenkins

Для начала, что это:
jenkins, он же hudson (что случилось) - инструмент непрерывной интеграции, написанный на Java.
Непрерывная интеграция - это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.
wiki

Итак.
Centos:
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins

Debian:
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
echo "deb http://pkg.jenkins-ci.org/debian binary/" >> /etc/apt/sources.list
sudo apt-get update
sudo apt-get install jenkins

По умолчанию сервис садится на порт 8080

линки
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+RedHat+distributions
http://pkg.jenkins-ci.org/debian/
http://habrahabr.ru/search/?q=[jenkins]&target_type=posts