¿Cómo hacer que las twigs de características de git funcionen con jenkins-workflow?

Estoy intentando configurar jenkins-workflow para hacer nuestras testings de integración. Nuestras testings de integración funcionan así:

Alguien hace un cambio a LibraryA en una twig de características en git. Nos gustaría que jenkins ejecutara las testings unitarias contra el código en la twig de características, luego nos gustaría instalar el código de esta twig de características en client2 y client2 (que son usuarios de LibraryA ) y ejecutar sus testings.

Pude configurar un flujo de trabajo para hacer todo, excepto get la confirmación correcta para la twig de características de LibraryA . En cambio, mi configuration simplemente extrae una confirmación de alguna twig (aparentemente aleatoria) de LibraryA .

Tenemos muchas twigs de características, por lo que no es apropiado codificar una determinada twig en la configuration del flujo de trabajo. Parece que debería haber alguna manera de get el hash de la confirmación que desencadena el trabajo del flujo de trabajo (incluso cuando se usa el sondeo de SCM).

Mi configuration se ve así:

 currentBuild.setDisplayName("#" + env.BUILD_NUMBER) node { git cnetworkingentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: 'git@github.com:mycompany/myrepo.git' sh ''' echo `git rev-parse HEAD` > libraryA_version.txt sudo docker run --rm=true -e LANG=en_US.UTF-8 -a stdout -i -t mycompany/libraryA run_tests ''' archive 'libraryA_version.txt' } def integration_jobs = [:] integration_jobs[0]={ node{ ws { unarchive mapping: ['libraryA_version.txt':'.'] sh 'sudo docker run -t --rm mycompany/client1:v1 bash run_tests.sh "`cat libraryA_version.txt`"' } } } integration_jobs[1] = { node{ ws { unarchive mapping: ['libraryA_version.txt' : '.'] sh 'sudo docker run -t --rm mycompany/client2 run_tests.sh "`cat libraryA_version.txt`" ' } } } parallel integration_jobs 

Entonces, mi pregunta actual es ¿cómo puedo configurar git repo / polling para get el compromiso correcto para ejecutar en la primera testing, que se usará en libraryA_version.txt en testings posteriores?

Alternativamente, ¿debería realizar este process de una manera completamente diferente?

Como lo insinuó @maybeg, lo que probablemente esté buscando es un proyecto de varias filas, disponible mediante la installation de Pipeline: Multibranch . Eso le permite definir el script en un Jenkinsfile que simplemente llama a checkout scm una o más veces en su compilation, evitando la necesidad de libraryA_version.txt .

Mientras tanto, me pregunto acerca de la configuration de tu proyecto. Tu paso de git es usar la branch: 'master' pnetworkingeterminada branch: 'master' , lo que significa que para empezar solo debería ser un sondeo en la twig master y solo verificar esta twig. El plugin de Git es bastante complicado, así que quizás esto esté roto de alguna manera. En espera del soporte multibranqueo adecuado, siempre puede usar el paso de GitSCM checkout con un GitSCM configurado para usar una especificación de twig comodín, en cuyo caso se seleccionará un encabezado de bifurcación no construido previamente para su extracción, y su truco git-rev-parse (supongo usted networkingescubrió de manera independiente la solución para JENKINS-26100 ) debería funcionar como está.

La function que está buscando es Build-Per-Branch y, en mi opinión, debería implementarse de acuerdo con los complementos adecuados.

  • La ramificación se hace en git.

  • Jenkins debe copyr el trabajo de compilation o compilation para adaptarse a la sucursal y poder build y probar la sucursal.

  • Después de la reintegración, Git debe informar a Jenkins y Jenkins debe cerrar los trabajos.

Encontré este complemento:

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

Y este plugin / tutorial:

http://entagen.github.io/jenkins-build-per-branch/

La implementación depende mucho de su escenario, así que no puedo ser más específico. Solo digo que los desafíos son:

  • Creación de trabajos de Jenkins que se pueden ejecutar de forma simultánea e independiente.

  • Trabajando con templates para trabajos de Jenkins.

  • Manejo de events entre Jenkins y git.

En tu caso:

  • Construya todo el process como una línea de entrega de principio a fin.

  • Si alguien ramifica un paso e implementa una function, copie toda la tubería y ejecute toda la tubería.

  • Haz que funcione y luego mejora.