Utilizzo di Hudson e generazione di passaggi con più repository git

Question

Sto provando con Hudson per sostituire la configurazione corrente di Buildbot. Ho installato il plugin git. La nostra messa a punto corrente è come:

ssh://server:/repo/test_framework.git 
ssh://server:/repo/project_a.git 

Ora, per costruire project_a ho aggiunto un nuovo lavoro con più repository Git (quelli sopra). Volevo che Hudson clonasse i repository in diverse directory sotto $WORKSPACE, perché la gerarchia ha bisogno di test_framework. Ma Hudson sembra fondere tutto in $WORKSPACE invece. Dal log della console:

warning: no common commits 
... 
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78 
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e 
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0 

Posso configurare questo a Hudson per adattare meglio la nostra messa a punto del progetto? Devo creare un repository git fittizio locale con ogni progetto come sottomoduli git o qualcosa del genere?

Answer 1

All'interno di Hudson è possibile concatenare più lavori. Potresti provare a creare lavori Hudson separati per test_framework e un altro per project_a. Hudson crea una directory separata in $ WORKSPACE per ogni lavoro, quindi ora dovresti avere due diverse directory in $ WORKSPACE.

---

Setup concatenazione

Nella configurazione di lavoro project_a scorrere verso il basso per le azioni di post-generazione e controllare costruire altri progetti ... Entra nel test_framework come il progetto per la costruzione.

Nella configurazione del lavoro di test_framework assicurarsi che Poll SCM sia deselezionato e che Genera dopo altri progetti sia impostato su project_a.

---

Come funziona

quello che hai ora configurato è project_a il polling del SCM alla ricerca di cambiamenti, quando si trovano cambiamenti che li tirare da Git. Esegui i passi della build (se ce ne sono) e al completamento attivano il lavoro test_framework per estrarre le modifiche da git (se presenti) ed eseguire i suoi passi di generazione.

Answer 2

Il problema con la soluzione "Costruisci altri progetti" è che se si apportano modifiche a test_framework non si attiverà il progetto_a da compilare. Invece, vi consiglio di abbandonare il plugin git e la creazione di un passo "Esegui guscio" costruire con il seguente:

rm -rf ${WORKSPACE}/* 

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework 
cd ${WORKSPACE}/test_framework 
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/* 
git ls-tree HEAD 

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a 
cd ${WORKSPACE}/project_a 
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/* 
git ls-tree HEAD 

successivo, creare file gancio "server: /repo/test_framework.git/hooks/post-receive" e "server: /repo/project_a.git/hooks/post-receive" con il seguente contenuto:

#!/bin/sh 
curl http://hudson/job/job_name/build 

Ora, ogni volta che le modifiche sono spinti a uno repository, il gancio utilizzerà le API di Hudson per innescare una generazione.

Answer 3

Mi sono imbattuto nello stesso problema e attualmente lo risolvo creando un lavoro per ogni progetto e utilizzando lo Copy Artifact Plugin per consentire la creazione del lavoro dipendente anche se un aggiornamento Git è fatto sulle sue dipendenze (questo per evitare di costruire nel mezzo di un aggiornamento del progetto da cui dipendiamo).

Quindi project_a copierà gli ultimi artefatti stabili di cui ha bisogno da test_framework e un aggiornamento al framework di test attiverà una build in project_a.project_a può ancora essere attivato da una modifica in Git, copia solo di nuovo gli ultimi artefatti in test_framework.

Answer 4

Mi rendo conto che questa domanda è molto antica, ma mi sono imbattuto nello stesso problema e ho usato questa pagina per arricchire la mia soluzione che sembra funzionare molto bene (anche se è un po 'contorto). La maggior parte del credito per questa soluzione dovrebbe andare a Clinton (l'unica ragione per cui mi sto prendendo la briga di presentare questa risposta è perché la sua risposta non sembra affrontare più repository che devono essere nella stessa directory di base).

Supponiamo di avere due repository (A e B).

Passi:

1) Fare due progetti per tirare codice dal repository remoti A e B. Mettere tutte le misure di compilazione necessarie in entrambi i repository.

2) Creare una terza directory senza alcuna gestione di controllo del codice sorgente. Aggiungere un passaggio di generazione a questo progetto per eseguire un comando di shell simile a questo: (. I suoi sentieri non può essere lo stesso di loro Guardate voi stessi!)

ln -s /var/lib/jenkins/jobs/A/workspace A 
ln -s /var/lib/jenkins/jobs/B/workspace B 

Ora è possibile aggiungere eventuali altre misure di build quello dipende da A e B che sono sorelle in una directory. Yay link simbolici!

3) Unire i tre compiti insieme. L'ordine delle attività di pull può o non può importare (lo sai meglio di me) ma l'attività senza il controllo del codice sorgente dovrebbe essere l'ultimo anello della catena.

Answer 5

Il problema si sta descrivendo è già archiviato come bug nel bugtracker Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-8082

---

Usiamo l'opzione "di lavoro personalizzata" nella configurazione di lavoro progetto esteso alla cassa repository del nostro lavoro in una sottodirectory di un altro lavoro.

che gli altri controlli di posti di lavoro la directory principale con tutti i sottomoduli:

var/lib/jenkins/jobs/ 
    + main_job 
    + workspace (main git checkout with submodules) 
     + modules 
     + mod1 
     + mod2 
    + mod1_job (custom workspace set to main_job/workspace/modules/mod1) 
    + workspace (empty)