Come rendere il polling SCM funzionante con il plug-in Jenkins Workflow

Question

In un normale progetto freestyle, configuro il plug-in SCM in modo che punti al repo Git che voglio rilasciare e abilito l'opzione "Poll SCM", che mi consente per configurare un webhook Stash per dire a Jenkins ogni volta che c'è stato un cambio a quel repository. In questo modo, il lavoro può essere attivato ogni volta che un cambiamento viene trasferito al repository.

Tuttavia, quando utilizzo un flusso di lavoro anziché un progetto stile libero, lo SCM del codice che ho bisogno di compilare viene specificato a livello di codice nello script del flusso di lavoro groovy, il che significa che non sta ascoltando il webhook di Stash. Invece, l'SCM che è configurato direttamente nel flusso di lavoro è l'SCM dello script groovy stesso, che è diverso dal codebase che sto cercando di creare/rilasciare, quindi non voglio che il trigger sia basato su questo.

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

Qualche idea su come ottenere il polling SCM quando si utilizza il plug-in del flusso di lavoro?

Answer 1

Ho risolto questa domanda con un sacco di ricerca e sperimentazione. Questa documentazione mi ha portato sulla strada giusta: https://github.com/jenkinsci/workflow-scm-step-plugin/blob/master/README.md. Dice:

Polling è supportato su più SCM (cambiamenti di uno o più attiveranno una nuova build), e ancora una volta è fatto secondo le MSC utilizzati nell'ultima build del flusso di lavoro "

.

Ciò significa che il polling SCM è ancora supportato con un flusso di lavoro Jenkins, ma a differenza di un normale progetto freestyle, è necessario eseguirlo manualmente prima di iniziare ad ascoltare le modifiche SCM. Questo ha senso perché gli SCM sono definiti nel codice Groovy; non sono noti fino a quando non vengono eseguiti una volta.

Un elemento difficile di questo è che è possibile definire molti SCM nel tuo flusso di lavoro. Ad esempio, ho tre: uno per il servizio stesso, uno script di distribuzione e il flusso di lavoro Groovy DSL. Per impostazione predefinita, le modifiche a uno di questi tre SCM causerebbero l'opzione "SCM poll" per attivare una build, che potrebbe non essere desiderabile. Fortunatamente, l'impostazione dell'opzione "poll: false" sul passo "git" nel codice Groovy disabiliterà il polling su quel repository. Se stai leggendo il tuo DSL Groovy da un SCM, puoi disabilitare il polling su quel repository facendo clic su "comportamenti aggiuntivi" nell'interfaccia utente di Jenkins e aggiungendo "Non attivare una build su notifiche di commit".

Un altro elemento difficile è che il plug-in del gancio Web di Stash include per impostazione predefinita il codice hash SHA1 del commit nell'URL RESTful con cui viene colpito Jenkins. Sfortunatamente, Jenkins commette l'errore di utilizzare lo stesso codice di commit quando tenta di estrarre uno qualsiasi degli SCM multipli che potresti aver definito. Ovviamente il codice hash è rilevante solo per un SCM, quindi si interrompe. È possibile aggirare questo impostando "Ometti SHA1 Hash Code" nel plug-in di web hook Stash. Quindi Jenkins userà l'ultimo commit su qualunque ramo tu costruisca da ciascuno dei tuoi SCM.