Есть ли хороший подход к автоматическому увеличению версий maven - PullRequest
Новая
       4

Есть ли хороший подход к автоматическому увеличению версий maven

1 голос
/ 11 июля 2020

Я уже давно этим занимаюсь, и вот текущий сценарий:

  • У меня есть ветка разработки, где после каждого sh pu я хочу публиковать sh my текущая библиотека maven как SNAPSHOT. В настоящее время я делаю это, используя exe c -plugin и echo для получения моей версии maven (например: -Dexe c .executable = echo -Dexe c .args = '$ {project.version}' org.codehaus .mojo: exe c -maven-plugin: 1.6.0: exe c))
  • Затем я использую команду update-versions, чтобы вставить в него "-SNAPSHOT" и publi sh (Я не публикую sh его обратно в ветку, так как не хочу сохранять «-SNAPSHOT»).

Для выпуска, я полагаю, я мог бы сделать что-то подобное где я получаю версию, затем выясняю способ ее увеличения -> publi sh обратно в текущую активную ветку -> и, наконец, выполняю развертывание. Прямо сейчас я выбрал немного более простой, хотя и подверженный ошибкам подход: я пытаюсь получить текущую версию, установленную в используемом нами артефакте, и, если она существует, я выхожу из конвейера с сообщением о том, что версия уже существует. Сейчас это не очень хорошо, потому что я на самом деле инвертирую здесь условие ошибки, поэтому, если maven выходит из строя по какой-либо другой причине, он фактически предполагает, что версия не существует, и продолжает переходить к следующим шагам. Тьфу.

Теперь, основные моменты, которые я здесь искал, действительно касаются лучшего метода обработки проектов maven и управления версиями. В идеале мои цели:

  • иметь возможность публиковать sh что-то как SNAPSHOT должным образом (возможно, без необходимости прибегать к maven-exe c)?
  • иметь возможность обновлять мою версию постепенно, чтобы пользователям не приходилось постоянно обновлять свою версию? Этот процесс, конечно же, должен гарантировать, что я не буду sh что-то освоить, что может иметь неправильную версию (которая затем не удалась бы при развертывании). Изменить: перефразируя, намерение здесь заключается не просто в увеличении версии «до следующей», а вместо «следующей доступной», гарантируя, что я не буду пытаться объединить версию, которая была опубликована ранее.

У меня есть одно ограничение: инструменты, которые мы используем, не позволяют нам использовать хуки слияния (Azure DevOps с Azure Git). Это означает, что мы ограничены конвейерами по вытягиванию (и PR) и после слияния PR.

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

Ответы [ 3 ]

1 голос
/ 11 июля 2020

Дополнение к ответу @davidxxx. Использование плагина build-helper maven может улучшить это: 

mvn build-helper:parse-version versions:set \
    -DnewVersion=\${parsedVersion.nextMajorVersion}.0.0 \
    versions:commit

или вот так: 

mvn build-helper:parse-version versions:set \
   - DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.nextMinorVersion}.0 \
   versions:commit

без каких-либо sed et c. подробнее:

1 голос
/ 11 июля 2020

затем используйте команду update-versions, чтобы вставить в него "-SNAPSHOT" и опубликовать sh (я не публикую sh его обратно в ветку, так как я действительно не хочу сохраните «-SNAPSHOT».

Не суждение, но использование версии без снимка в pom как для снимка, так и для выпуска чревато ошибками. Снимок означает «в разработчике, будьте осторожны». Выпуск означает «совсем стабильный, go ". В случае сомнений или отката к определенной версии c разработчики должны быть уверены в том, к чему относится фиксация. Здесь это размыто.

В идеале мой цели> следующие:

иметь возможность публиковать sh что-то как SNAPSHOT должным образом (возможно, без использования maven-exe c)?

Двумя способами:

  • сохраните версию артефакта как -SNAPSHOT в вашем pom. xml и обновите ее, удалив -SNAPSHOT и пометив / развернув ее, когда вы хотите рассматривать ее как выпуск.
  • оставьте версию артефакта no -SNAPSHOT (пока я не советую) и используйте удобную для maven-ci функцию / plugin , чтобы установить версию динамически.

Ваши свойства pom могут выглядеть как версия, определенная как: 

 <version>${revision}${sha1}${changelist}</version>

 <properties>
    <revision>1.0.0</revision>
    <changelist></changelist>
    <sha1/>
 </properties>

И вы также должны объявить flatten-maven-plugin как оставьте pom. xml расходным материалом для других проектов (как в случае с библиотеками).

Наконец, вы можете выполнить цель развертывания для pu sh вашего снимка в удаленном репозитории maven: 

mvn -Dchangelist=-SNAPSHOT clean deploy

иметь возможность обновлять мою версию постепенно, чтобы пользователям не приходилось постоянно обновлять свою версию? Этот процесс, конечно, должен гарантировать, что я не буду sh что-то освоить, что может иметь неправильную версию (которая затем не удалась при развертывании).

Вы можете положиться на плагины maven и сценарий для достижения этого. Например, для автоматического увеличения второго di git версии, которая не имеет префикса моментального снимка, как в вашем случае, в системе linux вы можете сделать: 

// get the current pom version and store it into a variable
version=$(mvn -q -U -Dexpression=project.version -DforceStdout maven-help-plugin:evaluate)
// increment the second digit of the version and overwrite the variable
version=$(echo ${version} |  awk -F'.' '{print $1"."$2+1"."$3}' |  sed s/[.]$//)
// update the pom with the new version
mvn -U versions:set -DnewVersion=${version}

Он работает как для версии с 3 цифрами, но также и с 2 цифрами благодаря sed.

0 голосов
/ 12 июля 2020

Мы создали инструмент (примечание: я работаю над ним) для отслеживания различных версий, схем и приращений для каждой ветки.

Вы можете определять свои схемы и ваши контакты для каждой ветки. Кроме того, вы не связаны SemVer, вы также можете использовать CalVer.

То есть для SemVer вы можете установить версию своего проекта на semver , а для ветки dev установить значение Major.Minor.Patch-SNAPSHOT . Затем он увеличит вашу основную ветку простым семвером, а ветка dev будет иметь суффикс -SNAPSHOT .

Здесь есть либо версия с открытым исходным кодом https://github.com/relizaio/versioning, либо версия SaaS по адресу https://relizahub.com (который имеет много дополнительных функций). Версия SaaS - это та версия, которая отслеживает предыдущие версии и позволяет выполнять чистое разделение на ветки через API.

Вот моя рецензия на подробности всего вышеперечисленного: https://worklifenotes.com/2020/02/27/automatic-version-increments-with-reliza-hub-2-strategies/

Примечание: Здесь все еще нужна команда для внедрения версии в ваш pom, для чего можно использовать следующее через плагин Versions Maven ( помимо предложений из других ответов): 

mvn versions:set -DnewVersion="$versionFromReliza"
...