java - studio - Cómo obtener el siguiente número de compilación en Gradle
rendimiento de android studio (5)
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
)
¿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''
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/
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
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.
- 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)