Comment obtenir le prochain numéro de build dans Gradle

Question

Existe-t-il un moyen d'obtenir la prochaine version lors de la publication vers un dépôt dans gradle ?

Par exemple, si j'ai la version 3.0.1 dans mon référentiel, je veux que la version publiée soit 3.0.2 .

ivy a une tâche à accomplir pour ant nommé buildnumber qui fait exactement cela :

<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>

Y a-t-il un moyen de le faire dans gradle ? si non, comment puis-je accéder ivy des tâches de gradle ant ?

Dans mon build.gradle J'appelle à la ant

ant.importBuild 'build.xml'

Answer 1

Je ne pense pas qu'il y ait de support dans Gradle, mais vous pouvez essayer d'utiliser la tâche Ant. https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

Une autre façon de procéder est d'utiliser une sorte de plugin, ou une tâche personnalisée pour gérer la version.

• Plugin : https://github.com/researchgate/gradle-release
• Tâche personnalisée : https://www.tikalk.com/devops/increment-version-numbers-in-gradle/

Answer 2

Oui, vous pouvez accéder aux tâches ivy à partir du script de ant en important le fichier build.xml de ant dans le fichier build.gradle de gradle. Voici la syntaxe pour le faire.

ant.importBuild 'build.xml' (en anglais)

Veuillez vous référer à : https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

Answer 3

Je vous recommande d'utiliser le plugin de publication de ResearchGate. https://github.com/researchgate/gradle-release La documentation est jolie. Facile à lire. Regardez aussi comment je l'ai utilisé dans mon projet personnel. https://github.com/vatolinrp/bitcoin-esb/blob/master/build.gradle Ce serait un bel exemple pour vous.

Answer 4

Après un long travail, j'ai réussi à le faire.

Dans mon build.gradle J'ai ajouté le code suivant

ant.importBuild 'build.xml'

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

J'ai importé mon ant et créé une tâche qui appelle la fonction ivy buildnumber tâche.

Il y a mon 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>

Parce que mon IDE (Intellij), n'avait pas ivy.jar dans le contenu,
J'ai importé le ivy.jar à partir de mon répertoire racine ( lib/ivy.jar )

Answer 5

• Pour ce comportement exact , Ivy buildnumber peut être invoquée en utilisant purement Gradle sans importer le build 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 } }

• En général Gradle n'a pas d'équivalent groupé à Maven Release Plugin, il faut donc compter sur les plugins. Un plugin solide est gradle-release par ResearchGate, l'autre est axion par Allegro Tech. Le premier est un versioning classique de type Maven, le second prend le SCM lui-même comme seule source de vérité, éliminant le versioning dans les fichiers de construction. Mais aucun de ces plugins ne fournit le comportement exact demandé.

• Mon point de vue personnel sur le problème du versioning était initialement d'utiliser certains plugins. Comme j'utilise Bamboo comme serveur de CI au travail, tout ce que j'ai fait avec les plugins de version en utilisant Gradle s'est écrasé sur le serveur de CI tôt ou tard. Cela a pu fonctionner pendant quelques semaines, mais chaque mise à jour du serveur apportait son lot de problèmes. J'ai fini par utiliser une approche sans SCM avec une convention simple : utiliser le nom de la branche comme version de base, le concaténer avec le numéro de build (les deux valeurs sont fournies par le serveur CI) :

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

Le serveur CI peut alors être configuré pour exécuter la commande suivante

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

quand on appuie sur le bouton "Release". Par exemple, la construction 12 de la branche 3.0 produira la version 3.0.12 dans le dépôt binaire.

Les avantages sont les suivants :
+ la version est gratuite, en supposant que les branches sont nommées en conséquence
+ le numéro de construction auto-incrémenté est également gratuit.
+ on peut publier facilement des rév rév rév révisions personnalisées
+ pas de plugins signifie pas de problèmes avec les mises à jour de la version de Gradle
+ cette approche est très simple et fonctionne toujours

Les inconvénients sont :
- des tâches supplémentaires script sont nécessaires pour les balises
- certains numéros de build seront évidemment ignorés (par exemple, la version suivante de la 3.5.76 peut être la 3.5.84).