Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Введение версионности артефактов при деплое

ci
gradle
jenkins
maven
Теги: #<Tag:0x00007f7b69a91168> #<Tag:0x00007f7b69a90da8> #<Tag:0x00007f7b69a90b78> #<Tag:0x00007f7b69a90998>

(Александр Шиповалов) #1

Коллеги, добрый день. Столкнулся с такой новой для меня задачей. Есть некий проект - состоящий из трех глобальных модулей (2-а на Maven и 1-н на Gradle) - 2 zip архива и war. Соответственно я захотел включать версии этих артфактов в отчет о тестировании, дабы избежать в будущем каких то непонятных вопросов. Проблема заключается в том, что сейчас никаких номеров версий не существует, кроме вполне традиционных
<version>...-SNAPSHOT</version>
Единственное место где эти модули как то пересекаются это CI сервер (Jenkins), однако и здесь возникает ряд вопросов - как взять ревизию CVS, куда логичнее сохранять эти версии или назначить какую то единую общую версию которая будет обновляться при деплое. В общем, нужен скорее совет по best practise, применяемыми в подобных случаях.


(Денис Тучин) #2

Очень странно звучит “проект - состоящий из трех глобальных модулей … Единственное место где эти модули как то пересекаются это CI сервер”
На продакшене наверняка тоже пересекаются? На сервере тестировани интеграции?
Если так, то разработчики обязаны нормально вести версионность, а не *-SNAPSHOT.
SNAPSHOT допускается до передачи на интеграционное тестирование, тут действительно нужно следить за номером ревизии. Тут непонятен вопрос “как взять ревизию CVS” - куда взять? Надеюсь поможет вот эта дока: https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project


(Александр Шиповалов) #3

На продакшене и стейджинге для тестирования они пересекаются, но там у них уже должны быть четко проставленные версии. Которые потом будут включаться в отчет. Если бы проект содержал один артефакт для мавен, то я мог бы взять например release plugin. Но мне надо, что бы при деплое версия всех модулей обновлялась, в том числе и Gradle. А вот это сделать централизовано я и спрашиваю.


(Александр Шиповалов) #4

Увы она не ведется. И PM, пока на них не наседает, потому, что они загружены другими задачами. Соответственно если мне это надо то мне и решать.


#5

Возможно, скажу очевидную вещь, которую Вы уже знаете.
Однако:

  • Сам Jenkins экспортирует ряд набор переменных среды при запуске билда, такие как BUILD_NUMBER, BUILD_ID и т.д.
  • Maven plugin (если он используется) при сборке также экспортирует некоторые переменные, например POM_VERSION (см. документацию по плагину). Наверняка, что-то такое есть и для Gradle.
  • Есть Version Number plugin, который дает еще больше переменных для конструирования версии.

А тестовому фреймворку можно всё это скормить или как параметр командной строки, или как еще одну переменную среды, а если это Java, то как property - главное, чтобы фреймворк этот параметр умел кушать.