Integración continua: ¿puede llamar a un repository svn desde un file build.xml?

Actualmente estoy construyendo un marco de integración continuo para el proyecto en el que estoy y me preguntaba si podría llamar a un repository svn desde un script, por ejemplo:

<target name="test" depends="clean"> <jmeter jmeterhome="${jmeter-home}" resultlog="results/jtl/JMeterTesting.jtl"> <testplans dir="http://example/svn/repository" includes="/**/jmxFiles/*.jmx"/> <!--<testplans dir="${jtesting-home}" includes="/**/jmxFiles/*.jmx"/>--> <property name="jmeter.save.saveservice.output_format" value="xml"/> <property name="jmeter.save.saveservice.assertion_results" value="all"/> <property name="jmeter.save.saveservice.bytes" value="true"/> <property name="file_format.testlog" value="${format}"/> <property name="jmeter.save.saveservice.response_data.on_error" value="${funcMode}"/> <property name="testData.fullPath" value="C:/TestData"/> </jmeter> </target> 

Por lo tanto, busca files .jmx dentro de http://exmaple/svn/repository .

Por qué, sí puede llamar a un repository de Subversion desde un script build.xml. Hay algunos problemas con esto:

  • ¿Cómo consigues tu script build.xml? ¿No está esto ya en el repository? ¿No tienes que hacer un pago para get el script de compilation?
  • ¿Qué sucede si hace una actualización y el script de construcción se actualiza?
  • ¿Qué revisión usaste para tu construcción? ¿El que rastreó Jenkins, o el que mandaste y actualizaste? Jenkins dice que esta compilation se realizó con la revisión 123456, pero debido a los cambios, podría ser la revisión 123457 o incluso 123458.

Siempre es mejor hacer sus llamadas a su sistema de control de versiones antes de acceder a su file build.xml. Afortunadamente, Jenkins lo hace muy, muy simple.

Si necesita el número de versión de Subversion para su process de compilation, está disponible en Jenkins en la variable de entorno $SVN_REVISION .

Podrías decir ¡ Pero lo que quiero almacenar en mi sistema de control de versiones son los resultados de mi construcción! . La respuesta: no debe almacenar resultados de compilation en Subversion.

Un problema es que los resultados de compilation ocupan mucho espacio en un sistema de control de versiones. Los files se almacenan en formatting delta . Es decir, solo se almacenan las diferencias entre las versiones. Puede tener miles de cambios en un file de text, y la cantidad de espacio necesario para almacenar todas esas revisiones es mínimo. Los files binarys son diferentes. Toman grandes cantidades de espacio. Peor aún, su vida útil es muy corta. Después de uno o dos años, el almacenamiento de control de versiones puede crecer en gigabytes, con el 90% del almacenamiento dedicado a nada más que a versiones binarias de files que nadie necesita.

Entonces, ¿Qué haces? Puede almacenar resultados de compilation directamente dentro de Jenkins. Crea un directory llamado archive o artifacts_, y copy tus resultados de compilation ahí. Luego, configure su trabajo Jenkins para save todos los resultados en este directory.

Si está utilizando comstackciones de Java (que supongo que porque está hablando de files build.xml), puede usar Maven o Ant con Ivy para almacenar sus files jar creados en un repository local de Maven. De esta forma, estos flasks están disponibles para sus otros proyectos. Nuevamente, no tiene que almacenarlos dentro de su sistema de control de versiones.


Ahora la respuesta real a tu pregunta …

Hay una tarea <svn/> , pero la mayoría de las personas encuentran que no funciona demasiado bien. Depende de JavaHL y SVN C API. En su lugar, simplemente usan la tarea <exec/> para llamar directamente a su cliente de Subversion.

El único problema aquí es que Jenkins usa SVNKit y no usa el cliente de línea de command. Asegúrese de que el directory de trabajo de compilation Jenkins SVNKit sea la misma versión de cliente que su cliente de línea de command SVN. Puede ajustar la versión del directory del cliente SVNKit en la configuration del sistema Jenkins.

Según doc :

plan de testing: utilice en lugar del atributo de plan de testing cuando desee especificar varios files del plan de testing. Este elemento es un elemento Ant FileSet estándar.

Así que puedes usar un set de files de ant estándar para este parámetro, pero ciertamente no es una url.

Le sugiero que escriba otra tarea de ant para hacer la comprobación de svn antes de ejecutar la tarea de jmeter. Echa un vistazo aquí para ver cómo puedes hacer eso.