Hudson verwenden und Schritte mit mehreren Git-Repositories erstellen

Question

Ich versuche Hudson, unser aktuelles Buildbot-Setup zu ersetzen. Ich habe das Git-Plugin installiert. Unsere aktuelle Setup ist wie:

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

, jetzt project_a zu bauen ich einen neuen Job mit mehreren Git-Repositories hinzugefügt (die, die weiter oben). Ich wollte, dass Hudson die Repositories in verschiedene Verzeichnisse unter $WORKSPACE klont, wobei test_framework diese Hierarchie benötigt. Aber Hudson scheint stattdessen alles in $WORKSPACE zusammenzuführen. Von dem Konsolenprotokoll:

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

Kann ich konfiguriere dies in Hudson, um besser unser Projekt Setup passen? Muss ich ein lokales Dummy-Git-Repository mit jedem Projekt als git-Submodule oder so erstellen?

Answer 1

Innerhalb von Hudson können Sie mehrere Jobs miteinander verketten. Sie könnten versuchen, separate Hudson-Jobs für test_framework und ein anderes für project_a zu erstellen. Hudson erstellt für jeden Job ein separates Verzeichnis in $ WORKSPACE, also sollten Sie jetzt zwei verschiedene Verzeichnisse unter $ WORKSPACE haben.

---

Setup-Chaining

In der Job-Konfiguration von project_a nach unten scrollen, um Aktionen Post-bauen und andere Projekte beim Aufbau überprüfen ... Geben Sie in test_framework als das Projekt zu bauen.

Stellen Sie in der Jobkonfiguration von test_framework sicher, dass Poll SCM nicht markiert ist und dass Build nach anderen Projekten auf project_a festgelegt ist.

---

Wie es

arbeitet Was haben Sie jetzt konfiguriert project_a ist die SCM Umfrage für Änderungen suchen, wenn Änderungen gefunden werden, wird es ihnen von git ziehen. Ausführen von Build-Schritten (falls vorhanden) und nach Abschluss den Job test_framework auslösen, um Änderungen von git zu übernehmen (falls vorhanden) und seine Build-Schritte auszuführen.

Answer 2

Das Problem mit der "Build andere Projekte" -Lösung ist, dass, wenn es Änderungen an test_framework gibt es keine Projekt_a zum Erstellen ausgelöst wird. Stattdessen empfehle ich die Git-Plugin zu verlassen und einen „Execute shell“ Build-Schrittes mit dem folgenden Einrichtung:

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 

Als nächstes Haken Dateien „Server: /repo/test_framework.git/hooks/post-receive“ erstellen und „Server: /repo/project_a.git/hooks/post-receive“ mit folgendem Inhalt:

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

Nun, wenn Änderungen gedrückt werden, um entweder Repository, wird der Haken Hudson API verwenden, um einen Build auszulösen.

Answer 3

Ich stieß auf das gleiche Problem und löste es derzeit, indem ich einen Job für jedes Projekt erstellte und Copy Artifact Plugin verwendete, um den abhängigen Job zu erstellen, selbst wenn ein Git-Update auf seinen Abhängigkeiten durchgeführt wurde (um das Erstellen in der Mitte zu vermeiden) eines Updates für das Projekt, von dem wir abhängig sind).

Also project_a würde die neuesten stabilen Artefakte kopieren, die es von test_framework benötigt, und ein Update auf das Testframework würde einen Build in project_a auslösen.project_a kann immer noch durch eine Änderung in Git ausgelöst werden, es kopiert nur die neuesten Artefakte in test_framework.

Answer 4

Ich weiß, dass diese Frage sehr alt ist, aber ich stieß auf das gleiche Problem und benutzte diese Seite, um meine eigene Lösung auszufüllen, die wirklich gut zu funktionieren scheint (obwohl es ein wenig verschachtelt ist). Der Hauptgrund für diese Lösung sollte Clinton sein (der einzige Grund, warum ich diese Antwort einreiche, ist, dass seine Antwort nicht mehrere Repositories zu adressieren scheint, die sich im selben Basisverzeichnis befinden müssen).

Angenommen, Sie haben zwei Repositories (A und B).

Schritte:

1) Machen Sie zwei Projekte Code von Remote-Repositories A ziehen und B. Setzen Sie die erforderlichen Build-Schritte in entweder Repository.

2) Erstellen Sie ein drittes Verzeichnis ohne Quellcodeverwaltung. Fügen Sie einen Build-Schritt zu diesem Projekt einen Shell-Befehl ähnlich wie dies auszuführen: (. Ihre Wege nicht gleich sein können Schauen sie auf sich selbst!)

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

Jetzt können Sie weitere Build-Schritte hinzufügen das hängt davon ab, dass A und B Schwestern in einem Verzeichnis sind. Yay symbolische Links!

3) Verketten Sie die drei Aufgaben zusammen. Die Reihenfolge der Pull-Tasks kann oder darf nicht wichtig sein (Sie wissen besser als ich), aber die Task ohne Quellcodeverwaltung sollte das letzte Glied in der Kette sein.

Answer 5

Das Problem, das Sie beschreiben, ist bereits als Fehler in dem Jenkins Bugtracker abgelegt: https://issues.jenkins-ci.org/browse/JENKINS-8082

---

Wir verwenden die „benutzerdefinierten Arbeitsbereich“ Option im erweiterten Projekt Job-Konfiguration unseres Jobs Repository in ein Unterverzeichnis zur Kasse von andere Arbeit.

Das andere Job checkt das Hauptverzeichnis mit allen Submodule:

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)