- PVSM.RU - https://www.pvsm.ru -

Автоинкремент версий в pom.xml через Jenkinsfile

Рано или поздно все разработчики Java решают мелкие задачи в области Continuos Integration. Не обошла эта участь и меня. Озадачился я проблемой автоматического инкремента версий в pom.xml при каждой итерации сборки проекта.

Дано: maven проект с несколькими модулями, мастер pom.xml и Jenkins-сервер (все как у настоящих пацанов).

Нужно: чтобы при каждом коммите автоматически собирался проект в любом бранче, а в ветке develop проект не только собирался, но и инкрементился номер билда, который задан третьим числом в версии вида 1.0.100-SNAPSHOT.

Для автоматической сборки Java-проекта в бранчах у нас используется Jenkins-проект на основе модного нынче Multibranch pipeline.

image

Суть этого workflow — периодически (например, раз в минуту), в Multibranch pipeline запускается задача, которая определяет изменения в бранчах и запускает сборку для тех бранчей, в которых что-то закоммитили. При этом, как у настоящих пацанов, для сборки бранча используется самый настоящий Jenkinsfile. Немного ликбеза: Jenkinsfile — это код на языке Groovy который определяет последовательность и инструкции по сборке проекта. Даже придумали для этого специальный термин «pipeline as code» [1]. Казалось, ничего вроде бы сложного нет — через groovy-скрипт инкрементим номер версии, коммитим и запускаем maven-сборку. Но тут нарисовывается главная проблема — как предотвратить последующие (бесконечные) сборки после того, как мы автоматом обновили pom.xml? Да, в Jenkins-плагине под названием 'git' (тот самый, который предназначен для детекта изменений в бранчах) есть даже специальная фича — «Pooling ignores commit», но вот незадача — она не работает в Multibranch-pipeline. По этому поводу жаловались многие пользователи и даже завели специальный Jira-айтем [2]. Поэтому — вперед, будем изобретать свой велосипед!

Но к счастью, в git-плагине работает другая фича «Exclude branches». Поэтому заведем специальный бранч, куда будем коммитить только номера билдов при каждой сборке и добавим название этого бранча в исключения (чтобы новые коммиты не вызывали триггеринг новых сборок). Фактически, этот бранч нужен только для того, чтобы хранить одно число, которое указывает на номер билда. Такой бранч не имеет предков и называется «сирота». Для его создания сделаем следующее:

git checkout --orphan develop2
git reset --hard

И разместим в нем файл с именем current.tag, в который запишем номер билда. Ну а далее все за вас сделает Jenkinsfile, исходный текст которого найдете в репозитории на гитхабе [3].

Не буду больше утомлять вас кодом, вкратце, алгоритм Jenkinsfile такой:

  1. Склонировали проект
  2. Переключились на сиротливый бранч
  3. Прочитали номер последнего билда
  4. Увеличили номер билда
  5. Прикопали номер билда в переменной и записали его в файл в сиротливой бранч
  6. Переключились в основной бранч
  7. Распарсили номер версии из pom.xml
  8. Сгенерировали номер версии на основе версии из pom.xml и номером билда
  9. Проапдейтили версию в мастер pom.xml и всех его модулях при помощи соответствующего maven-плагина
  10. Собрали проект при помощи mvn package

В итоге получаем такую красоту:

image

Автор: getaclue

Источник [4]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/java/214878

Ссылки в тексте:

[1] «pipeline as code»: https://jenkins.io/doc/book/pipeline-as-code/

[2] специальный Jira-айтем: https://issues.jenkins-ci.org/browse/JENKINS-36836

[3] репозитории на гитхабе: https://github.com/get-a-clue/maventemplate.git

[4] Источник: https://habrahabr.ru/post/316364/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best