build process - travis - Compartir artefactos de construcción entre trabajos en Hudson
jenkins tutorial (8)
Estoy tratando de configurar nuestro proceso de compilación en Hudson.
El trabajo 1 será un trabajo de construcción de integración continua extremadamente rápido (con suerte) que se construirá con frecuencia.
El trabajo 2 será responsable de ejecutar un conjunto de pruebas completo, en un intervalo regular o desencadenarse manualmente.
Job 3 será responsable de ejecutar las herramientas de análisis en la base de código (al igual que Job 2).
Intenté utilizar la función "Opciones de proyectos avanzadas> uso de espacio de trabajo personalizado" para que el código compilado en el Trabajo 1 se pueda usar en el Trabajo 2 y 3. Sin embargo, parece que todos los artefactos de construcción permanecen dentro del espacio de trabajo del Trabajo 1. Estoy haciendo esto, ¿verdad? ¿Hay una mejor manera de hacer esto? Supongo que estoy buscando algo similar a una configuración de compilación ... para que las cosas se puedan compartir y los trabajos apropiados se puedan ejecutar por etapas.
(También consideré usar "tareas por lotes" ... pero parece que no se pueden programar, ¿solo se activan manualmente?)
Cualquier sugerencia es bienvenida. ¡Gracias!
¿Has mirado la wiki de Hudson? Específicamente: dividir un gran trabajo en trabajos más pequeños
Es posible que desee probar el plugin Copy Artifact:
http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin
Su trabajo continuo puede construir los artefactos necesarios, y sus otros dos trabajos pueden atraerlos para hacer análisis.
Estoy de acuerdo en que los archivos de copia actuales / artefactos / espacios de trabajo entre trabajos de forma manual son menos que elegantes.
Además, me pareció un desperdicio espacio / tiempo tener que archivar enormes archivos tgz / zip. En nuestro caso, estos archivos eran enormes (1.5G) y demoraron mucho en empacar / archivar / tomar huellas dactilares / descomprimir.
Así que me conformé con una variante ligeramente optimizada de la misma:
- El trabajo 1/2/3 revisa / clona el mismo repositorio fuente, pero
- El trabajo 1 solo empaqueta archivos que en realidad son artefactos de construcción
- con Git hace que esto sea fácil y rápido por
git ls-files -oz
, no estoy seguro acerca de otros SCM
- con Git hace que esto sea fácil y rápido por
- use el plugin Copy Artifact para transferir archivos
- Esto reduce los archivos a un tamaño de 1/3 en nuestro caso -> aceleración, menos espacio desperdiciado
Estoy haciendo algo así ahora. Recomiendo evitar cualquier intento de ejecutar muchos trabajos en el mismo espacio de trabajo compartido. Solo he tenido problemas con eso.
Estoy usando maven y el tipo de proyectos de forma libre. Un conjunto de trabajos se ejecuta cuando los archivos en el sistema de control de versiones lo activan. Crean artefactos locales de instantáneas. Un segundo conjunto de trabajos se ejecuta cada noche y configura un entorno de prueba de integración y luego ejecuta pruebas en él.
Si no estás usando maven; Una opción es configurar un área en el disco y hacer que los pasos finales en el trabajo uno copien los artefactos en ese punto. Los primeros pasos del trabajo dos deberían ser mover esos archivos. Corre lo que necesites ejecutar.
En cuanto al tercer trabajo, hay findbugs / checkstyle / pmd y todos los complementos para Hudson ahora. Yo recomendaría simplemente crear una versión del trabajo 1 que haga un pago limpio por la noche y se ejecute en su base de código.
Hudson no parece tener un repositorio integrado para artefactos de construcción. Nuestra solución fue crear uno.
Estamos en un entorno de Windosw, así que creé un recurso compartido al que podían acceder todos los servidores de Hudson (brindamos a los servicios relevantes una cuenta común ya que la cuenta del sistema no puede acceder a los recursos a través de una red).
Dentro de nuestros scripts de compilación (ant), tenemos tareas que copian la creación de recursos de otros trabajos en el espacio de trabajo local y los trabajos que generan artefactos los copian en el repositorio común.
En otros entornos, puede publicar y buscar a través de FTP o cualquier otro mecanismo para mover archivos.
Ejemplos simplistas de tareas de publicación y obtención:
<!-- ==================== Publish ==================================== -->
<target name="Publish" description="Publish files">
<mkdir dir="${publish.dir}/lib" />
<copy todir="${publish.dir}/lib" file="${project.jar}"/>
</target>
y
<!-- ==================== Get ==================================== -->
<target name="getdependencies" description="Get necessary results from published directory">
<copy todir="${support.dir}">
<fileset dir="${publish.dir}/lib">
<include name="*.jar"/>
</fileset>
</copy>
</target>
Hudson tiene un complemento para este problema: http://wiki.hudson-ci.org/display/HUDSON/Clone+Workspace+SCM+Plugin (enlace actualmente roto)
La página correspondiente de Jenkins está aquí: https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin
Sí, esa página wiki no fue muy útil porque intenta hacer que suene muy elegante. La verdad es que Hudson no es compatible con las cadenas de trabajo de forma muy elegante, sin embargo, si tiene que pasar cosas de un trabajo a otro.
También estoy haciendo el método zip-up-and-copy-workspace para transferir espacios de trabajo de un trabajo a otro. Tengo una compilación rápida, compilación de análisis completo y luego compilaciones de distribución. Mientras tanto, utilizo Ant para generar marcas de tiempo y "sellos de compilación" para marcar el número de trabajo que se creó y el número de otro trabajo. La función de huellas digitales ayuda a mantener un registro de los archivos, pero como no voy a archivar las cremalleras del espacio de trabajo, las huellas dactilares son inútiles para los usuarios porque no pueden ver las cremalleras del espacio de trabajo.
Tuve el mismo problema, y lo que terminé yendo con proyectos separados para las tareas de larga ejecución. El primer paso en estos proyectos fue copiar todos los archivos del espacio de trabajo del Trabajo 1 (es decir, la última compilación) a los espacios de trabajo de Job 2/3 / etc. Por lo general, esto funcionó a menos que Job 1 se estuviera creando en el momento en que comenzó Job 2/3, ya que obtendría un espacio de trabajo incompleto. Podría solucionar esto al detectar "fin de compilación" en la tarea 1 con un archivo centinela, o usar el complemento Hudson Locks (no lo he intentado).
No tiene que usar un espacio de trabajo personalizado si realiza suposiciones sobre la ubicación de los otros trabajos en relación con% WORKSPACE%.