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

Question

Sto provando Hudson per sostituire la nostra attuale configurazione Buildbot. Ho installato il plugin git. La nostra configurazione attuale è come:

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

Ora, per creare project_a ho aggiunto un nuovo lavoro con più repository git (quelli sopra). Volevo che Hudson clonasse i repository in diverse directory in $ WORKSPACE , perché test_framework ha bisogno di quella gerarchia. Invece Hudson sembra fondere tutto in $ WORKSPACE . Dal registro 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 configurarlo in Hudson per adattarlo meglio alla configurazione del nostro 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 insieme. 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 directory diverse in $ WORKSPACE.

---

Impostazione del concatenamento

Nella configurazione del lavoro di project_a scorrere verso il basso fino a Azioni post-build e selezionare Crea altri progetti ... Immettere test_framework come progetto da costruire.

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

---

Come funziona

Ciò che hai ora configurato è project_a eseguirà il polling di SCM alla ricerca di modifiche, quando vengono rilevate le modifiche le estrarrà da git. Esegui i passaggi di compilazione (se presenti) e al termine attiva il processo test_framework per estrarre le modifiche da git (se presenti) ed eseguirne i passaggi.

Answer 2

Il problema con " Crea altri progetti " la soluzione è che se ci sono modifiche a test_framework, questo non attiverà la creazione di project_a. Invece, ti consiglio di abbandonare il plug-in git e impostare una " Execute shell " costruire passo 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

Successivamente, crea i file hook " 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 vengono inviate a uno dei repository, l'hook utilizzerà l'API di Hudson per attivare una build.

Answer 3

Mi rendo conto che questa domanda è molto vecchia, ma ho riscontrato lo stesso problema e ho usato questa pagina per perfezionare la mia soluzione che sembra funzionare davvero bene (anche se è un po 'contorta). La maggior parte del merito di questa soluzione dovrebbe andare a Clinton (l'unica ragione per cui mi preoccupo di inviare questa risposta è perché la sua risposta non sembra indirizzare più repository che devono trovarsi nella stessa directory di base).

Supponi di avere due repository (A e B).

Passi:

1) Crea due progetti per estrarre il codice dai repository remoti A e B. Inserisci tutti i passaggi necessari per la compilazione in entrambi i repository.

2) Crea una terza directory senza alcuna gestione del controllo del codice sorgente. Aggiungi un passaggio di compilazione a questo progetto per eseguire un comando shell simile a questo:

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

(I tuoi percorsi potrebbero non essere gli stessi. Guardali tu stesso!)

Ora puoi aggiungere qualsiasi altro passaggio di compilazione che dipende dal fatto che A e B siano sorelle in una directory. Yay link simbolici!

3) Incatenare le tre attività insieme. L'ordine delle attività pull può o meno avere importanza (lo sai meglio di me) ma l'attività senza controllo del codice sorgente dovrebbe essere l'ultimo anello della catena.

Answer 4

Ho riscontrato lo stesso problema e attualmente risolto creando un lavoro per ciascun progetto e utilizzando Copia plug-in artefatto per consentire la creazione del lavoro dipendente anche se un aggiornamento Git viene eseguito sulle sue dipendenze (questo per evitare la creazione nel mezzo di un aggiornamento del progetto da cui dipendiamo) .

Quindi project_a copia 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 innescato da una modifica in Git, copia solo gli ultimi artefatti in test_framework.

Answer 5

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

---

Usiamo lo spazio di lavoro personalizzato " " opzione nella configurazione estesa del lavoro di progetto per effettuare il checkout del repository del nostro lavoro in una sottodirectory di un altro lavoro.

L'altro lavoro verifica 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)