Автоинкремент версій 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». Здавалося, нічого начебто складного немає — через 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 такий:

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

image
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.