Рано или поздно все разработчики Java решают мелкие задачи в области Continuos Integration. Не обошла эта участь и меня. Озадачился я проблемой автоматического инкремента версий в pom.xml при каждой итерации сборки проекта.
Дано: maven проект с несколькими модулями, мастер pom.xml и Jenkins-сервер (все как у настоящих пацанов).
Нужно: чтобы при каждом коммите автоматически собирался проект в любом бранче, а в ветке develop проект не только собирался, но и инкрементился номер билда, который задан третьим числом в версии вида 1.0.100-SNAPSHOT.
Для автоматической сборки Java-проекта в бранчах у нас используется Jenkins-проект на основе модного нынче Multibranch pipeline. 
Суть этого workflow — периодически (например, раз в минуту), в Multibranch pipeline запускается задача, которая определяет изменения в бранчах и запускает сборку для тех бранчей, в которых что-то закоммитили. При этом, как у настоящих пацанов, для сборки бранча используется самый настоящий Jenkinsfile. Немного ликбеза: Jenkinsfile — это код на языке Groovy который определяет последовательность и инструкции по сборке проекта. Даже придумали для этого специальный термин «pipeline as code». Казалось, ничего вроде бы сложного нет — через groovy-скрипт инкрементим номер версии, коммитим и запускаем maven-сборку. Но тут нарисовывается главная проблема — как предотвратить последующие (бесконечные) сборки после того, как мы автоматом обновили pom.xml? Да, в Jenkins-плагине под названием ‘git’ (тот самый, который предназначен для детекта изменений в бранчах) есть даже специальная фича — «Pooling ignores commit», но вот незадача — она не работает в Multibranch-pipeline. По этому поводу жаловались многие пользователи и даже завели специальный Jira-айтем. Поэтому — вперед, будем изобретать свой велосипед!
Но к счастью, в git-плагине работает другая фича «Exclude branches». Поэтому заведем специальный бранч, куда будем коммитить только номера билдов при каждой сборке и добавим название этого бранча в исключения (чтобы новые коммиты не вызывали триггеринг новых сборок). Фактически, этот бранч нужен только для того, чтобы хранить одно число, которое указывает на номер билда. Такой бранч не имеет предков и называется «сирота». Для его создания сделаем следующее:
git checkout --orphan develop2 git reset --hardи разместим в нем файл с именем current.tag, в который запишем номер билда. Ну а далее все за вас сделает Jenkinsfile, исходный текст которого найдете в репозитории на гитхабе.
Не буду больше утомлять вас кодом, вкратце, алгоритм Jenkinsfile такой:
- Склонировали проект
- Переключились на сиротливый бранч
- Прочитали номер последнего билда
- Увеличили номер билда
- Прикопали номер билда в переменной и записали его в файл в сиротливой бранч
- Переключились в основной бранч
- Распарсили номер версии из pom.xml
- Сгенерировали номер версии на основе версии из pom.xml и номером билда
- Проапдейтили версию в мастер pom.xml и всех его модулях при помощи соответствующего maven-плагина
- Собрали проект при помощи mvn package
В итоге получаем такую красоту:
ссылка на оригинал статьи https://habrahabr.ru/post/316364/
Добавить комментарий