Автоматическое Увеличение Версий В Pom.xml Через Jenkinsfile

Рано или поздно все Java-разработчики решают небольшие проблемы в области Continuos Integration. Меня эта судьба тоже не пощадила.

Меня озадачила проблема автоматического приращения версий в pom.xml при каждой итерации сборки проекта.

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

Необходимо, чтобы при каждом коммите проект автоматически собирался в любой ветке, а в ветке разработки проект не только собирался, но и увеличивался номер сборки, который в версии вида 1.0 указывается как третье число.

.

100-МОНИТ.

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



Суть этого рабочего процесса в том, что периодически (например, раз в минуту) в Multibranch Pipeline запускается задача, которая обнаруживает изменения в ветках и запускает сборку для тех веток, в которых что-то было коммитировано.

При этом, как и настоящие мальчики, для сборки ветки используется настоящий Jenkinsfile. Немного образовательной информации: Jenkinsfile — это код на языке Groovy, определяющий последовательность и инструкции по сборке проекта.

Для этого даже придумали специальный термин «конвейер как код» .

Казалось бы, ничего сложного — с помощью groovy-скрипта инкрементируем номер версии, коммитируем и запускаем maven-сборку.

Но тут возникает главная проблема — как предотвратить последующие (бесконечные) сборки после того, как мы автоматически обновили pom.xml? Да, в плагине Jenkins под названием 'git' (тот самый, который предназначен для обнаружения изменений в ветках) даже есть специальная функция — «Опрос игнорирует коммиты», но вот незадача — она не работает в Multibranch-pipeline. Многие пользователи жаловались на это и даже начали специальный элемент Jira .

Поэтому вперед, давайте изобретать велосипед! Но к счастью, в плагине git работает еще одна функция «Исключать ветки».

Поэтому мы создадим специальную ветку, где будем коммитить только номера сборок для каждой сборки и добавим в исключения имя этой ветки (чтобы новые коммиты не запускали новые сборки).

Фактически эта ветка нужна только для хранения одного числа, обозначающего номер сборки.

Такая ветвь не имеет предков и называется «сиротой».

Для его создания сделаем следующее:

   

 git checkout --orphan develop2
 git reset --hard

   

Ну а дальше за вас все сделает Jenkinsfile, исходный текст которого можно найти в репозитории на GitHub .

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

1. Клонировать проект
2. Переключился на одинокий бранч
3. Прочитайте номер последней сборки
4. Увеличен номер сборки
5. Мы запрятали номер сборки в переменную и записали его в файл на одиноком бранче.

6. Перешел на основной бранч
7. Проанализировал номер версии из pom.xml.
8. Сгенерирован номер версии на основе версии из pom.xml и номера сборки.

9. Обновлена версия в главном pom.xml и всех его модулях с использованием соответствующего плагина maven.
10. Мы собрали проект с использованием пакета mvn.

• Продажа Сломанного Ноутбука: Ноутбуки Против Amazon

  19 Oct, 24

• Наращивание Трафика - Покупаете Ли Вы Трафик Веб-Сайта, Чтобы Получать Прибыль В Интернете?

  19 Oct, 24

• Идеальные Игры Для Молодых Женщин

  19 Oct, 24

• Докланд — Сервис По Организации Лечения За Рубежом

  19 Oct, 24

• Изучаем Mitre Att&Ck. Мобильные Матрицы: Доступ К Устройствам. Часть 5

  19 Oct, 24

• Mobile Backhaul Для Небольшого Мобильного Оператора

  19 Oct, 24

• Spacex Снова Откладывает Запуск Falcon 9

  19 Oct, 24

• В Рунете Есть Цензура

  19 Oct, 24

• Вефай

  19 Oct, 24

• Какие Слова Чаще Всего Используются В Названиях Мобильных Приложений На Ios?

  19 Oct, 24