create - Cómo hacer que el sondeo SCM funcione con el complemento Jenkins Workflow

jenkins-pipeline-python

Question

En un proyecto de estilo libre normal, configuro el complemento SCM para que apunte al repositorio de Git que quiero liberar, y habilito la opción "Encuesta SCM", que me permite configurar un webhook Stash para decirle a Jenkins siempre que haya habido un cambio a ese repo. De esta manera, el trabajo puede activarse cada vez que se empuje un cambio al repositorio.

Pero cuando uso un flujo de trabajo en lugar de un proyecto de estilo libre, el SCM del código que debo compilar se especifica mediante programación en el script de flujo de trabajo maravilloso, lo que significa que no está escuchando el webhook de Stash. En cambio, el SCM que se configura directamente en el flujo de trabajo es el SCM de la secuencia de comandos groovy, que es diferente del código base que estoy intentando crear / lanzar, por lo que no quiero que el desencadenante se base en eso.

node(''docker_builder'') {
git url: serviceRepo
releaseVersion = getVersion()
pipelineSpec = getPipelineSpec()
sh "./gradlew clean build pushDockerImage"
}

¿Alguna idea sobre cómo lograr el sondeo de SCM al usar el complemento de flujo de trabajo?

Answer 1

He resuelto esta pregunta con mucha investigación y experimentación. Esta documentación me llevó por el camino correcto: https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md . Dice:

El sondeo se admite en varios SCM (los cambios en uno o más activarán una nueva compilación), y nuevamente se realizan de acuerdo con los SCM utilizados en la última compilación del flujo de trabajo ".

Esto significa que el sondeo de SCM aún es compatible con un flujo de trabajo de Jenkins, pero a diferencia de un proyecto de estilo libre normal, debe ejecutarlo una vez manualmente antes de que comience a escuchar los cambios de SCM. Esto tiene sentido porque los SCM están definidos en el código Groovy; No se conocen hasta que se ejecutan una vez.

Un elemento delicado de esto es que puede definir muchos SCM en su flujo de trabajo. Por ejemplo, tengo tres: uno para el servicio en sí, una secuencia de comandos de implementación y el DSL de flujo de trabajo de Groovy. De forma predeterminada, los cambios en cualquiera de esos tres SCM podrían hacer que la opción "Encuesta SCM" active una compilación, lo que puede no ser conveniente. Afortunadamente, configurar la opción "poll: false" en el paso "git" en el código Groovy deshabilitará el sondeo en ese repositorio. Si está leyendo su Groovy DSL desde un SCM, puede deshabilitar el sondeo en ese repositorio haciendo clic en "comportamientos adicionales" en la interfaz de usuario de Jenkins y agregando "No activar una compilación en las notificaciones de confirmación".

Otro elemento complicado es que el complemento de enganche web Stash incluye de forma predeterminada el código hash SHA1 de la confirmación en la URL RESTful con la que golpea a Jenkins. Desafortunadamente, Jenkins comete el error de usar el mismo código de confirmación cuando intenta extraer cualquiera de los múltiples SCM que puede haber definido. El código hash, por supuesto, solo es relevante para un SCM, por lo que se rompe. Puede solucionar esto configurando "Omitir SHA1 Hash Code" en el complemento de enganche web Stash. Luego, Jenkins solo usará la última confirmación en cualquier rama que construyas en cada uno de tus SCM.