Как получить следующий номер сборки в Gradle

Есть ли способ получить следующую версию при публикации в хранилище в градиенте?

Например, если у меня есть версия 3.0.1 в моем репозитории, я хочу, чтобы опубликованная версия была 3.0.2.

ivy имеет задачу ant по имени buildnumber, который делает именно это:

<project xmlns:ivy="antlib:org.apache.ivy.ant"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<target name="ivyBuildNumber" description="Use ivy get the next build number">
    <ivy:buildnumber
        resolver="url-chain"
        organisation="${ivy.organisation}"
        module="${ivy.module}"
        revision="${version.base}"/>

    <echoproperties prefix="ivy.new."/>
</target>

Есть ли способ сделать это в gradle? если нет, то как я могу получить доступ к задачам ivy из ant?

В моем build.gradle я призываю ant

ant.importBuild 'build.xml'

Ответ 1

После долгой работы мне удалось это сделать.

В моем build.gradle я добавил следующий код

ant.importBuild 'build.xml'

task getNextBuild(dependsOn : ivyBuildNumber) {
    doLast{
        def nextVersion = ant.properties['ivy.new.revision']
        println nextVersion
    }
}

Я импортировал свой ant файл сборка, и создал задачу, которая вызывает ivy buildnumber задачи.

Есть мой файл build.xml

<project xmlns:ivy="antlib:org.apache.ivy.ant">

    <target name="ivyBuildNumber">
        <path id="ivy.classpath" path="lib/ivy.jar" />
        <typedef resource="org/apache/ivy/ant/antlib.xml" uri="antlib:org.apache.ivy.ant" classpathref="ivy.classpath" />
        <ivy:buildnumber
            organisation="daniel"
            module="hello"/>
        <echoproperties prefix="ivy.new."/>
    </target>
</project>

Поскольку моя IDE (Intellij) не ivy.jar в контенте,
Я импортировал ivy.jar из моего корневого lib/ivy.jar (lib/ivy.jar)

Ответ 2

Я не думаю, что в Gradle есть поддержка, но вы можете попробовать использовать задачу Ant. https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

Другой способ сделать это - использовать какой-то плагин или настраиваемую задачу для управления версией.

Плагин: https://github.com/researchgate/gradle-release
Пользовательская задача: https://www.tikalk.com/devops/increment-version-numbers-in-gradle/

Ответ 3

Да, вы можете получить доступ к задачам плюща из скрипта ant, импортировав файл ant build.xml в файл gradly build.gradle. Ниже приведен синтаксис для этого.

ant.importBuild 'build.xml'

См. Https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

Ответ 4

Я рекомендую использовать плагин для выпуска ResearchGate https://github.com/researchgate/gradle-release. У него довольно документация. Легко читается. Кроме того, ознакомьтесь с тем, как я использовал его в своем личном проекте. https://github.com/vatolinrp/bitcoin-esb/blob/master/build.gradle Это был бы хороший пример для вас.

Ответ 5

Для этого точного поведения задача Ivy buildnumber может быть вызвана с использованием чистого Gradle без импорта сборки Ant:

configurations {
    antTasks // define a new configuration
}

repositories {
    mavenCentral()
}

dependencies {
    antTasks("org.apache.ivy:ivy:2.4.0") // add Ivy library to it
}

ext {
    // define the Ivy task, using the extra configuration as classpath extension
    ant.taskdef(name: "ivyBuildNumber", 
                classname: "org.apache.ivy.ant.IvyBuildNumber", 
                classpath: configurations.antTasks.asPath) 

    ant.ivyBuildNumber(organisation: "daniel", module: "hello")
    nextVersion = ant.properties["ivy.new.revision"]
}

task demo {
    doLast {
        println nextVersion
    }
}

В общем, Gradle не имеет в комплекте эквивалент Maven Release Plugin, поэтому приходится полагаться на плагины. Один сплошной плагин - градиентный релиз от ResearchGate, другой - аксель от Allegro Tech. Первый - это классическое исполнение версий в стиле Maven, последнее берет SCM как единственный источник правды, устраняя управление версиями в файлах сборки. Но ни один из этих плагинов не обеспечивает точного запроса.
Мое личное решение проблемы с версией было первоначально использовать некоторые плагины. Поскольку я использую Bamboo в качестве сервера CI на работе, буквально все, что я делал с плагинами выпуска с использованием Gradle, сбой на сервере CI рано или поздно. Возможно, он работал несколько недель, но каждое обновление сервера вызвало некоторые проблемы. В итоге я использовал метод SCM-less с простым соглашением: используйте имя ветки в качестве базовой версии, объедините его с номером сборки (оба значения предоставлены сервером CI):

ext {
    branch = System.getProperty("branch", "develop")
    buildNumber = System.getProperty("buildNumber", "latest")
    isRelease = System.getProperty("isRelease", "false").toBoolean()
    artifactVersion = "${branch}${(isRelease ? ".$buildNumber" : "-SNAPSHOT")}"
}

Затем сервер CI может быть настроен для выполнения следующей команды

./gradlew -DisRelease=true -Dbranch=${git.branch} -DbuildNumber=${build.number} mavenPublish

когда нажата кнопка "Отпустить". Например, построение 12 из ветки 3.0 приведет к выпуску версии 3.0.12 в двоичном репозитории.

Преимущества:
+ версия предоставляется бесплатно, предполагая, что ветки названы соответственно
+ номер с автоматически увеличивающимся номером также предоставляется бесплатно
+ можно легко публиковать собственные изменения
+ плагинов нет проблем с обновлением версии Gradle
+ этот подход мертв просто и всегда работает

Недостатками являются:
- нет тегов (никаких изменений вообще нет в SCM - нет ветвей выпуска и т.д.), но так как номер сборки всегда известен, можно просмотреть ревизию в истории сборки CI
- некоторые числа сборки будут пропущены, очевидно (например, следующая версия после 3.5.76 может быть 3.5.84)