Mit Hudson und Erstellungsschritte mit mehreren git Repositories

Question

Ich versuche, aus Hudson zu unserem aktuellen Buildbot Setup zu ersetzen. Ich installierte die git-Plugin. Unsere aktuelle Setup ist wie:

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

Nun zu bauen project_a habe ich einen neuen Job mit mehreren Git-Repositories (die, die weiter oben). Ich wollte Hudson die Repositories in verschiedene Verzeichnisse unter $WORKSPACE klonen, becase test_framework dass Hierarchie muss. Aber Hudson scheint stattdessen alles in $WORKSPACE zu verschmelzen. 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 dies in Hudson konfigurieren, um besser unser Projekt Setup passen? Brauche ich einen lokalen Dummy Git Repository mit jedem Projekt als git Submodule oder etwas zu schaffen?

Answer 1

Innerhalb Hudson Sie zusammen mehrere Jobs Kette. Sie könnten versuchen, getrennte Hudson Jobs für test_framework und eine andere für project_a zu schaffen. Hudson schafft ein eigenes Verzeichnis in $ ARBEITSBEREICH für jeden Job, jetzt sollten Sie zwei verschiedene Verzeichnisse unter $ ARBEITSBEREICH haben.

---

Setup Chaining

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

In der Job-Konfiguration von test_framework sicherzustellen, dass Poll SCM ist nicht markiert und bauen, die nach anderen Projekten werden auf project_a.

---

Wie es funktioniert

Was haben Sie jetzt konfiguriert ist project_a die SCM Umfrage für Änderungen suchen, wenn Änderungen gefunden werden es wird sie von git ziehen. Führen Sie bauen Schritte (falls vorhanden) und nach Abschluss lösen die test_framework Job ziehen Änderungen von git (falls vorhanden) und führen ihre Build Schritte.

Answer 2

Das Problem mit der „Build andere Projekte“ Lösung ist, dass, wenn es Änderungen wird es nicht project_a zu bauen auslösen test_framework sind. 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 erstellen Haken Dateien "Server: /repo/test_framework.git/hooks/post-receive" und "Server: /repo/project_a.git/hooks/post-receive" mit folgendem Inhalt:

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

Nun, wenn Änderungen an entweder Repository geschoben werden, wird der Haken Hudson API verwenden, um einen Build auslösen.

Answer 3

Ich weiß, diese Frage ist sehr alt, aber ich lief in das gleiche Problem und verwenden diese Seite an meine eigene Lösung zu konkretisieren, die wirklich gut zu funktionieren scheint (obwohl es ein bisschen gewunden ist). Die meisten der Kredit für diese Lösung zu Clinton (der einzige Grund, warum ich stört diese Antwort zu unterbreiten ist, weil seine Antwort scheint nicht mehrere Repositories zu adressieren, die in der gleichen Basisverzeichnis sein müssen) gehen sollte.

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

Schritte:

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

2) Stellen Sie ein drittes Verzeichnis ohne Quellcodeverwaltung. Fügen Sie einen Build-Schritt zu diesem Projekt eines Shell-Befehl ähnlich wie dies auszuführen:

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

(Ihre Pfade können nicht gleich sein. Schauen sie auf sich selbst!)

Jetzt können Sie alle anderen Build-Schritte hinzufügen, die in einem Verzeichnis auf A und B Schwestern ab. Yay symbolische Links!

3) -Kette, die drei Aufgaben zusammen. Die Reihenfolge der Pull-Aufgaben kann oder auch keine Rolle, (Sie wissen besser als ich), aber die Aufgabe ohne Quellcodeverwaltung sollte das letzte Glied in der Kette sein.

Answer 4

ich in das gleiche Problem lief und löste es zur Zeit durch einen Auftrag für jedes Projekt zu erstellen und mit dem Copy Artifact Plugin auch den Aufbau der abhängigen Arbeit zu ermöglichen, wenn ein Git-Update auf seine Abhängigkeiten erfolgt (dies ist Gebäude in der Mitte eines Updates für das Projekt zu vermeiden, die wir abhängen) .

So project_a das letzte stabile Artefakte kopieren würde es von test_framework benötigt und ein Update auf Test-Framework würde einen Build in project_a auslösen. project_a kann immer noch durch eine Änderung in Git ausgelöst werden, es ist nur Kopien wieder die neuesten Artefakte in test_framework.

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 eines anderen Jobs zur Kasse.

Die 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)