Рано или поздно все разработчики 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' (тот самый, который предназначен для детекта изменений в бранчах) есть даже специальная фича — «Polling ignores commits», но вот незадача — она не работает в Multibranch-pipeline. По этому поводу жаловались многие пользователи и даже завели специальный Jira-айтем. Поэтому — вперед, будем изобретать свой велосипед!

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

git checkout --orphan develop2
git reset --hard

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

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

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

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