web-dev-qa-db-fra.com

Comment obtenir le prochain numéro de build dans Gradle

Existe-t-il un moyen d'obtenir la prochaine version lors de la publication dans un référentiel 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 pour ant nommée 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>

Existe-t-il un moyen de le faire dans gradle? sinon, comment puis-je accéder aux tâches ivy depuis le ant de gradle?

Dans mon build.gradle J'appelle au ant

ant.importBuild 'build.xml'
javagradleantivy
27
Daniel Taub

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

Dans mon build.gradle j'ai ajouté ce code suivant

ant.importBuild 'build.xml'

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

J'ai importé mon fichier de génération ant et créé une tâche qui appelle la tâche ivybuildnumber .

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 depuis mon répertoire racine (lib/ivy.jar)

5
Daniel Taub

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 le faire est d'utiliser une sorte de plugin ou une tâche personnalisée pour gérer la version.

10
chenrui

Oui, vous pouvez accéder aux tâches ivy à partir du script 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'

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

8
sricheta ruj

Je vous recommande d'utiliser le plugin de publication ResearchGate https://github.com/researchgate/gradle-release Il a une jolie documentation. Facile à lire. Découvrez également 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.

6
rastaman
  • Pour ce comportement exact , la tâche Ivy buildnumber peut être invoquée en utilisant Gradle pur sans importer la génération 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 fourni avec Maven Release Plugin, il faut donc se fier aux plugins. Un plugin solide est gradle-release par ResearchGate, l'autre est axion par Allegro Tech. Le premier est un versionnage classique de style Maven, le second prend SCM lui-même comme la seule source de vérité, éliminant le versioning dans les fichiers de build. Mais aucun de ces plugins ne fournit le comportement exact demandé.

  • Mon point de vue personnel sur le problème de versionnage consistait initialement à utiliser certains plugins. Depuis que j'utilise Bamboo comme serveur CI au travail, littéralement tout ce que j'ai fait avec les plugins de version utilisant Gradle s'est écrasé tôt ou tard sur le serveur CI. Cela a peut-être fonctionné pendant quelques semaines, mais chaque mise à jour du serveur a posé des 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

lorsque le bouton "Release" est enfoncé. Par exemple, la build 12 de la branche 3.0 produira la version 3.0.12 dans le référentiel binaire.

Les avantages sont:
+ la version est gratuite, en supposant que les branches sont nommées en conséquence
+ le numéro de build incrémenté automatiquement est également gratuit
+ on peut facilement publier des révisions personnalisées
+ aucun plugin signifie aucun problème avec les mises à jour de la version Gradle
+ cette approche est très simple et fonctionne toujours

Les inconvénients sont:
- des tâches de script supplémentaires sont requises pour les balises
- certains numéros de build seront sautés, évidemment (par exemple, la prochaine version après 3.5.76 peut être 3.5.84)

3
jihor