Sto provando a configurare jenkins-workflow per eseguire i nostri test di integrazione. I nostri test di integrazione funzionano in questo modo:Come far funzionare le branch feature git con jenkins-workflow?
Qualcuno apporta una modifica a LibraryA
in un ramo di funzione in git. Vorremmo che jenkins eseguisse i test unitari contro il codice nel ramo delle funzionalità, quindi vorremmo installare il codice da questo ramo di funzionalità in client1
e client2
(che sono utenti di LibraryA
) ed eseguire i test.
Sono stato in grado di configurare un flusso di lavoro per fare tutto tranne ottenere il commit corretto per il ramo di funzionalità di LibraryA
. Invece, il mio setup richiama semplicemente un commit da qualche ramo (apparentemente casuale) di LibraryA
.
Abbiamo molti rami di funzionalità, quindi una codifica particolare nella configurazione del flusso di lavoro non è appropriata. Sembra che ci dovrebbe essere un modo per ottenere l'hash del commit che attiva il lavoro del flusso di lavoro (anche quando si usa il polling SCM).
La mia configurazione è simile al seguente:
currentBuild.setDisplayName("#" + env.BUILD_NUMBER)
node {
git credentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: '[email protected]: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
Quindi, la mia domanda corrente è come posso installare il git repo/polling per ottenere il giusto impegnarsi a correre nel primo test, che sarà utilizzato in libraryA_version.txt
nei test successivi?
In alternativa, dovrei andare su questo processo in un modo completamente diverso?
Questo è quello che temevo. Questo è il modo in cui abbiamo iniziato. Abbiamo una catena di strumenti multi-lavoro che funziona, ma ha qualità indesiderabili. Non è scalabile con i nostri repository, nel senso che abbiamo troppi lavori da gestire. Le notifiche di errore e i colpevoli non funzionano bene. L'impostazione tra i lavori è poco pratica. Questo è il motivo per cui il plugin jenkins-workflow è bello: l'installazione per un'intera catena di integrazione è in un unico, abbastanza compatto lavoro. – Robert
Quindi lascia rispondere alla tua domanda originale, ecco un elenco delle variabili env del lavoro di jenkins: https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project. Nel tuo caso GIT_COMMIT e GIT_BRANCH dovrebbero essere le informazioni che cerchi nella costruzione del tuo flusso di lavoro. – blacklabelops
Stampo i miei oggetti env nella parte superiore del lavoro e quelli non sono disponibili. Apparentemente, il lavoro di Jenkins-workflow non imposta quelle variabili GIT. "Le seguenti variabili sono attualmente disponibili all'interno di uno script di workflow: EXECUTOR_NUMBER NODE_NAME NODE_LABELS spazio di lavoro variabili SCM-specifici come SVN_REVISION" – Robert