2015-07-10 13 views
5

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?

risposta

0

La funzione che stai cercando è Build-Per-Branch e, a mio avviso, dovrebbe essere implementata di conseguenza tramite plugin adatti allo scopo.

  • La ramificazione è fatta in git.

  • Jenkins deve copiare il processo di generazione o generazione della pipeline affinché si adatti al ramo e sia in grado di creare e testare il ramo.

  • Dopo la reintegrazione, Git deve informare Jenkins e Jenkins deve chiudere i lavori.

ho trovato questo plugin:

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

E questo plugin/tutorial:

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

La realizzazione è fortemente dipendente dello scenario, quindi non posso essere più specifico. Dico solo che le sfide sono:

  • Creazione di lavori Jenkins che possono essere eseguiti contemporaneamente e in modo indipendente.

  • Utilizzo di modelli per lavori Jenkins.

  • Gestione eventi tra Jenkins e Git.

Nel tuo caso:

  • costruire l'intero processo come tubazione di mandata dalla parte anteriore alla fine.

  • Se qualcuno dirama un passaggio e implementa una funzione, copia l'intera pipeline ed esegui l'intera pipeline.

  • Ottenere questo funzionamento quindi migliorare.

+0

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

+0

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

+0

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

3

Come @maybeg accennato, ciò che è più probabile cercando è un progetto multiramo, disponibile installando Pipeline: multiramo. Ciò consente di definire lo script in uno Jenkinsfile che chiama semplicemente checkout scm una o più volte nella build, evitando la necessità di libraryA_version.txt.

Nel frattempo, mi viene da chiedersi sulla configurazione del progetto. Il passo git utilizza il valore predefinito di branch: 'master', il che significa che deve iniziare solo il polling sul ramo master e solo il controllo di questo ramo. Il plugin Git è piuttosto complicato, quindi forse questo è rotto in qualche modo. In attesa del corretto supporto multibranch, è possibile utilizzare sempre il passaggio checkout con un configurato per utilizzare una specifica di ramo jolly, nel qual caso verrà selezionato per il checkout un ramo di diramazione arbitrario non creato in precedenza e il trucco git-rev-parse (suppongo che tu abbia riscoperto in modo indipendente il soluzione alternativa per JENKINS-26100) dovrebbe funzionare così com'è.

+0

Ok, quindi, per riflettere, in un lavoro di flusso di lavoro, configurare il polling scm per attivare il lavoro quando viene eseguito un commit, quindi utilizzare il passaggio 'checkout' con un ramo jolly (**). Selezionerà un ramo con una testa che non è stata costruita, idealmente il ramo del commit che ha attivato il lavoro? – Robert

+0

Giusto, non vi è alcuna garanzia che il commit testa selezionato sia la causa del trigger, ma è probabile. Non è sicuro che cosa accadrà se vengono scoperte più teste idonee in una sessione di polling: potrebbe innescare più build, anche se si usa il polling SCM (incl.il webhook '/ git/notifyCommit') è saggio aggiungere' @ daily'/'@ hourly' al programma per catturare eventuali commit vaganti. Ancora una volta, usando un flusso di lavoro multibranch imminente tutto diventa più semplice: ogni ramo ottiene il proprio sottoprogetto, e la notazione 'checkout scm' può essere usata ≥1 volte per ottenere checkout corrispondenti. –

+0

Sono stato in grado di utilizzare la nomenclatura 'branch:" production "' con il nuovo plug-in di lavoro Pipeline sotto Jenkins ver. 1.634. – MarkHu