Как бороться с семантическим версионированием в Jenkins
Я начинаю Дженкинс на моем рабочем месте. Мы используем семантическое управление версиями с Teamcity, и я хочу реализовать то же самое в Jenkins. Моя проблема возникает, когда я сохраняю артефакты в папке builds ($JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER), потому что Jenkins использует только build_number для создания папки для сборки, поэтому, когда мне придется сбросить de Build_number, будущие артефакты будут хранится в папке предыдущих сборок.
Например:
У меня хранится сборка 1.3.1_develop.1, когда я сбрасываю Build_Number, следующая сборка должна быть 1.3.2_develop.1, и она должна храниться в папке 1 сборки 1.3.1_develop.1
Мой вопрос заключается в том, может ли кто-нибудь объяснить мне, как бороться с автоматическим семантическим версионированием на jenkins, потому что мы сбрасываем номер сборки, мы увеличиваем мэра, младший номер и номер патча.
Jenkins Версия: 2.89.4 Jobs-> Мы используем задания для компиляции Vuejs для front и для развертывания обратно с python (если это поможет)
Спасибо за любую помощь.
1 ответ
Первое, что я заметил, это то, что вы неправильно используете семантическое управление версиями. 1.3.1_develop.1 должно быть 1.3.1-develop+1, Метаданным сборки всегда должен предшествовать символ "+" плюс, и они не учитываются в порядке сортировки SemVer.
Во-вторых, номер сборки никогда не "сбрасывается", он может в конечном итоге перевернуться, но его никогда не следует сбрасывать. Номер сборки, который не указывает на машину, выполняющую сборку, также обычно бесполезен, если только он не может быть только один.
По сути, в семантическом управлении версиями нет номера сборки. Стандарт определяет синтаксис для метаданных сборки, но абсолютно нейтрален в отношении того, что может быть включено. Номера сборки, как правило, бесполезны на уровне семантического контроля версий. Они используются для предотвращения конфликтов каталогов в системах сборки CI и даже предоставляют уникальный идентификатор для некоторых линий продуктов (например, Windows), особенно когда семантическое управление версиями не используется (снова Windows).
Я рекомендую использовать SHA-1 или более лучший хэш входных данных для сборки (например, Git commit Id) в метатеге сборки в дополнение к любому счетчику сборки и использовать его в качестве имени выходного каталога. Вы по-прежнему можете использовать монотонный счетчик и для ваших предварительных тегов, но вам нужно будет создать имя выходного каталога компоновки, которое будет содержать всю строку semver, чтобы сохранить уникальность.
В-третьих, ваша сборочная машина - худшее место для архивации ваших сборочных артефактов! Автоматизация сборки время от времени может идти ужасно неправильно. Ваша система сборки не должна иметь доступа к вашему архиву артефактов сборки. Когда ваша сборка и первоначальное тестирование дыма завершены, он должен сигнализировать о процессе, работающем на совершенно другой машине, чтобы переместить артефакты со сборочной машины в более безопасное место. Ни один процесс, работающий в системе сборки, не должен иметь права на запись в ваш архив артефактов сборки.
Есть инструмент GitVersion который делает то, что вы хотите, и его можно интегрировать с Jenkins или другим CI.
https://gitversion.readthedocs.io/en/latest/build-server-support/build-server/jenkins/