Solución alternativa: resultados agregados de la prueba de flujo descendente

Question

Hasta donde yo sé, la función "resultados agregados de la prueba aguas abajo" no funciona como se esperaba (y es muy difícil encontrar documentación útil). Me gustaría conseguir una funcionalidad muy similar:

Trabajo Build desencadena empleos T1, T2 en paralelo (donde T1 hace FindBugs, T2 hace PMD).

Escenario 1: Tan pronto como T1 y T2 están acabados (que puedo lograr usando el plugin "Join") Quiero recoger los artefactos (T1 /findbugs.xml y T2/pmd.xml). Luego, estos se analizan y se generan buenas estadísticas.

Escenario 2 (me gusta este más): Como escenario 1, pero el análisis se realiza como parte de T1 y T2 (en paralelo). Tan pronto como terminen T1 y T2, los resultados del análisis se combinan en buenas estadísticas.

Mis preguntas: para el escenario 1 no sé cómo hacer referencia a los proyectos aguas abajo T1 y T2 . Podría usar la última compilación exitosa, pero parece extraño cuando considero muchos trabajos paralelos.

para el escenario 2 no tengo ni idea de cómo importar los datos que se necesita para la FindBugs/PMD/Checkstyle/SLOCCount/plugins ... por lo que los gráficos correspondientes (?) También aparecerá fuera de T1/* T2 *.

Gracias, Carsten

Answer 1

Dos adiciones al post de malenkiy_scot:

1. En realidad no necesita un script para el paso 3 en la descripción: Los "artefactos copia de otro proyecto" construir paso permite especificar el trabajo de origen incluyendo parámetros ya .

   Por ejemplo, utilizando la notación del elemento principal, puede copiar artefactos de la ejecución correcta del trabajo D utilizando D/PARENT_ID=EXPECTED_VALUE como el "nombre del proyecto".

2. En lugar de la concatenación de forma manual y $JOB_NAME$BUILD_ID puede utilizar la predefinido $BUILD_TAG (que básicamente hace lo mismo). Consulte https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-JenkinsSetEnvironmentVariables para obtener la lista completa de variables de entorno estándar.

Answer 2

He aquí un esquema para un escenario algo más simple, pero creo que se puede generalizar fácilmente a su caso de varios trabajos posteriores. El truco es usar parámetros de "marcado" en trabajos posteriores.

Vamos P ser el trabajo de los padres y D ser un trabajo corriente abajo.

1. Una instancia (build) de P invoca D través de Parameterized Trigger Plugin a través de un paso de generación (no como un paso posterior a la generación) y espera a que D 's para terminar. Junto con otros parámetros, P pasa a D un parámetro - llamémosla PARENT_ID - basado en la acumulación de P 's ID_creación.
2. D ejecuta las pruebas y las archiva como artefactos (junto con los informes jUnit, si corresponde).
3. P continuación, ejecuta una pitón externa (o interna maravilloso) script que se encuentra la construcción adecuada de D través PARENT_ID (iterar sobre obra de D y examinar el valor de parámetro PARENT_ID). El script luego copia los artefactos de D a P y P los publica.

Si utilizo Python (eso es lo que hago) - utilice Python JenkinsAPI wrapper. Si usa Groovy, utilice Groovy Plugin y ejecute su secuencia de comandos como secuencia de comandos del sistema. A continuación, puede acceder a Jenkins a través de su Java API.

Answer 3

Jenkins Plugin https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin debería ayudar en dichos requisitos.