Encuesta SCM incorrecta en trabajos de múltiples proyectos desde la migration de SVN a GIT

Sé que se trata de un software obsoleto, pero por favor tengan paciencia conmigo. Estamos utilizando la última versión de la twig Jenkins v1.x. Habiendo migrado de Subversion a git, necesitamos reconfigurar nuestro CI para usar git. Un trabajo necesita para pagar dos proyectos y build ambos para ejecutar los exámenes. Dado que el plugin git no permite ver diferentes proyectos en diferentes directorys (ver JENKINS-4535 y los diversos seguimientos – TLDR: no se implementó), estamos usando el plugin Multiple SCM para lograr eso.

Ahora nos está picando el hecho de que el sondeo de SCM no funciona correctamente en esta configuration y Jenkins ejecuta el trabajo todas las veces, incluso si no hay cambios. Encontré esta solución para cuando estás revisando dos twigs diferentes del mismo proyecto, pero en nuestro caso, estamos revisando la misma twig de proyectos diferentes . Supongo que esta es la razón por la que la solución mencionada no funcionará, ya que el especificador de sucursal es exactamente el mismo para ambos proyectos.

¿Hay algo que podamos intentar para que esta configuration se ejecute correctamente? Tenga en count que hay mucho trabajo de transición que hacer desde la migration a git y, por lo tanto, la actualización de Jenkins a v2.x o el uso de interconexiones, aunque definitivamente previsto, es algo que realmente nos gustaría evitar en este momento.

Intente separar el polling de la salida : podría definir dos trabajos de "desencadenante" adicionales , cada uno de los sondeos de uno de sus proyectos individualmente. Tras un cambio, cada uno de ellos activaría su trabajo principal (que luego realiza el pago real a través del complemento Muliple SCM).

Decidimos actualizar Jenkins a 2.x y usar el DSL de canalización declarativa , ya que nuestra configuration parecía imposible de migrar con un set idéntico de trabajos (sin embargo, la solución de Alex O es una idea clara usando trabajos de desencadenador adicionales) y parece ser la correcta forma de mantenerse al día con Jenkins.

Aquí hay un esqueleto del script que hemos creado. No pudimos hacer funcionar un sondeo SCM declarativo ( triggers / pollSCM ), simplemente nunca se activó (pero no estamos solos en este caso ). Sin embargo, la configuration de un disparador SCM "clásico" a través del editor funciona. Es un poco incómodo, pero está bien por ahora.

 pipeline { agent any stages { stage('checkout') { steps { checkout([ $class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[ $class: 'RelativeTargetDirectory', relativeTargetDir: 'project1']], submoduleCfg: [], userRemoteConfigs: [[ cnetworkingentialsId: '...', url: '...']] ]) checkout([ $class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[ $class: 'RelativeTargetDirectory', relativeTargetDir: 'project2']], submoduleCfg: [], userRemoteConfigs: [[ cnetworkingentialsId: '...', url: '...']] ]) } } stage('build') { steps { sh '...' } } stage('test') { steps { sh '...' } } } }