java - studio - Cómo obtener el siguiente número de compilación en Gradle

rendimiento de android studio

Question

¿Hay alguna forma de obtener la próxima versión al publicar en un repositorio en gradle?

Por ejemplo, si tengo la versión 3.0.1 en mi repositorio, quiero que la versión publicada sea 3.0.2 .

ivy tiene una tarea para la ant denominada buildnumber que hace exactamente eso:

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

¿Hay una manera de hacerlo en gradle ? Si no, ¿cómo puedo acceder a las tareas de ivy de la ant de Gradle?

En mi build.gradle llamo a la ant

ant.importBuild ''build.xml''

Answer 1

Después de un largo trabajo, logré hacer eso.

En mi build.gradle agregué este siguiente código

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

Importé mi archivo de compilación ant y creé una tarea que llama a la tarea de buildnumber ivy .

Ahí está mi 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>

Debido a que mi IDE (Intellij), no tenía ivy.jar en el contenido,
ivy.jar el ivy.jar desde mi directorio raíz ( lib/ivy.jar )

Answer 2

No creo que haya soporte en Gradle, pero puedes intentar usar la tarea Ant. https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

Otra forma de hacer esto es usar algún tipo de complemento o tarea personalizada para administrar la versión.

• Plugin: https://github.com/researchgate/gradle-release
• Tarea personalizada: https://www.tikalk.com/devops/increment-version-numbers-in-gradle/

Answer 3

Sí, puede acceder a las tareas de hiedra desde el script ant importando el archivo build.xml de ant al archivo build.gradle de gradle. A continuación se muestra la sintaxis para hacerlo.

ant.importBuild ''build.xml''

Consulte: https://docs.gradle.org/current/userguide/ant.html#sec:import_ant_build

Answer 4

Te recomiendo usar el complemento de lanzamiento de ResearchGate https://github.com/researchgate/gradle-release Tiene una bonita documentación. Fácil de leer. Además, mira cómo lo usé en mi proyecto personal. https://github.com/vatolinrp/bitcoin-esb/blob/master/build.gradle Sería un buen ejemplo para usted.

Answer 5

• Para este comportamiento exacto , la tarea Ivy buildnumber puede invocarse usando Gradle puro sin importar la compilación 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 general , Gradle no tiene ningún paquete equivalente a Maven Release Plugin, por lo que uno tiene que confiar en los plugins. Un complemento sólido es https://github.com/researchgate/gradle-release de ResearchGate, el otro es axion de Allegro Tech. El primero es el versionado clásico al estilo Maven, el último toma a SCM como la única fuente de verdad, eliminando el versionado en los archivos de compilación. Pero ninguno de estos complementos proporciona el comportamiento exacto solicitado.

• Mi opinión personal sobre el problema de las versiones inicialmente fue usar algunos complementos. Ya que uso Bamboo como servidor de CI en el trabajo, literalmente todo lo que hice con los complementos de lanzamiento que usan Gradle se estrelló en el servidor de CI, tarde o temprano. Puede que haya funcionado durante algunas semanas, pero cada actualización del servidor trajo algunos problemas. Terminé usando el enfoque de SCM-less con una convención simple: usar el nombre de la rama como versión base, concatenarla con el número de compilación (ambos valores son proporcionados por el servidor de CI):

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

El servidor CI se puede configurar para ejecutar el siguiente comando

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

cuando se presiona el botón ''Release''. Por ejemplo, la compilación 12 de la rama 3.0 producirá la versión 3.0.12 en el repositorio binario.

Las ventajas son:
+ la versión viene gratis, asumiendo que las ramas son nombradas en consecuencia
+ el número de compilación auto-incrementado también viene gratis
+ Uno puede publicar fácilmente revisiones personalizadas
+ sin complementos significa que no hay problemas con las actualizaciones de la versión Gradle
+ este enfoque es muerto simple y siempre funciona

Las desventajas son:
- sin etiquetas (sin cambios en SCM - sin sucursales de lanzamiento, etc.), pero como el número de compilación siempre se conoce, se puede ver la revisión en el historial de compilaciones de CI
- algunos números de compilación se omitirán, obviamente (por ejemplo, la próxima versión después de 3.5.76 puede ser 3.5.84)