Git-Submodule werden in Jenkins Build nicht aktualisiert

84

Ich habe ein Submodul in einem Projekt in Jenkins. Ich habe die erweiterte Einstellung aktiviert, um Submodule rekursiv zu aktualisieren.

Wenn ich den Build ausführe, sehe ich, dass der Arbeitsbereich die Dateien aus dem Submodul enthält. Das Problem ist, es scheint die erste Überarbeitung des Submoduls zu sein. Wenn ich Änderungen vorschiebe (auf GitHub gehostetes Repository), scheint Jenkins das Submodul nicht zu aktualisieren, um die richtigen Änderungen zu erhalten. Hat jemand das jemals gesehen?

git jenkins git-submodules

— Ben
quelle

95

Beachten Sie, dass das Jenkins Git-Plugin 2.0 "erweiterte Submodul-Verhaltensweisen" aufweist, die eine ordnungsgemäße Aktualisierung der Submodule sicherstellen sollten:

Wie kommentiert von vikramvi:

Advanced sub-modules behavior> " Path of the reference repo to use during submodule update" Fügen Sie für dieses Feld die Git-URL des Submoduls hinzu.

Owen B erwähnt in den Kommentaren :

Für das Authentifizierungsproblem gibt es jetzt die Option "Anmeldeinformationen vom Standard-Remote des übergeordneten Repositorys verwenden"

Hier in JENKINS-20941 gesehen :

— VonC
quelle

6

Aber wie? Können Sie auch detaillierte Schritte angeben, welche Optionen zur Auswahl stehen? Vielen Dank.

— Zavié

8

@ zavié Ich denke, Sie sollten "Erweitertes Verhalten von Submodulen" auswählen und dann das Kontrollkästchen "Submodule rekursiv aktualisieren" aktivieren, das angezeigt wird, und auf Speichern klicken.

— KajMagnus

9

Dies funktioniert nicht ganz, wenn Sie ein privates Repository verwenden.

— Erik

1

Arbeitete perfekt für mich mit einem privaten Repo

— davegallant

3

Dies funktioniert nur, wenn Ihr Repo keine Authentifizierung zum Lesen Ihres Git-Submoduls erfordert. Jenkins Bug.

— Ernst Kuschke

32

Dies wird in der Dokumentation zum Git-Plugin auf der Jenkins-Site unter dem Abschnitt: Rekursive Submodule behandelt .

Auszug

Das GIT-Plugin unterstützt Repositorys mit Submodulen, die wiederum selbst Submodule haben. Dies muss jedoch aktiviert sein: in Jobkonfiguration -> Abschnitt Quellcodeverwaltung , Git -> Erweiterte Schaltfläche (unter Zu erstellende Zweige) -> Rekursive Aktualisierung von Submodulen .

Beispiel

Klicken Sie im Konfigurationsbildschirm Ihres Jobs im Abschnitt Quellcodeverwaltung auf die Schaltfläche Hinzufügen und wählen Sie "Erweitertes Verhalten der Submodule".

Wählen Sie dann "Submodule rekursiv aktualisieren":

— slm
quelle

1

Danke, aber das hat nicht funktioniert, als ich es versucht habe (vor fast 2 Jahren)

— Ben

@ Ben - OK, ich habe es gerade versucht und es hat bei mir funktioniert. Könnte mit Ihren Versionen zusammenhängen.

— Slm

1

Dies funktioniert nur, wenn Ihr Repo keine Authentifizierung zum Lesen Ihres Git-Submoduls erfordert.

— Ernst Kuschke

@ErnstKuschke - Ich glaube, Jenkins kann einen SSH-Schlüssel erhalten, damit er auch mit Repos interagieren kann, für die eine Authentifizierung erforderlich ist.

— Slm

29

Ist Ihnen bewusst, dass sich Ihr Git-Repository immer auf eine bestimmte Revision eines Submoduls bezieht ? Jenkins wird die Revision nicht automatisch ändern.

Wenn Sie eine neuere Version des Submoduls verwenden möchten, müssen Sie dies in Ihrem lokalen Git-Repository tun:

cd submoduledir
git pull
cd ..
git add submoduledir
git commit -m 'Updated to latest revision of submoduledir'
git push # Go and watch Jenkins build with the new revision of the submodule

Wenn Sie dies so tun, überprüft Jenkins während des Builds genau die gleiche Version des Submoduls. Jenkins entscheidet nicht selbst, welche Revision des Submoduls verwendet werden soll. Dies ist der grundlegende Unterschied zwischen Git-Submodulen und SVN-Externals.

Vielleicht möchten Sie eine gute Referenz zu Submodulen lesen, z . B. http://progit.org/book/ch6-6.html .

— sti
quelle

1

Der von @sti angegebene ProGit-Link ist veraltet. Ich denke, dies ist das aktuelle Äquivalent https://git-scm.com/book/en/v2/Git-Tools-Submodules

— Stevel

Die Verbindung ist unterbrochen (HTTPS-bezogen?) - "502 Bad Gateway" .

— Peter Mortensen

17

Schließlich stolperte über einen Weg, dies zu tun und es ist einfach.

Das Thema:

Das anfängliche Klonen mit Anmeldeinformationen funktioniert einwandfrei, das nachfolgende submoduleKlonen schlägt jedoch mit falschen Anmeldeinformationen fehl.

Automatisches Klonen von erweiterten Submodulen :: Source Code Management >> Additional Behaviours >> Advanced sub-modules behavioursführt zu einem Anmeldeinformationsfehler.
git submodule update --initin dem Execute ShellAbschnitt schlägt auch mit Anmeldeinformationsfehler fehl.

Die Lösung:

Ich benutze jenkins-1.574.

Aktivieren Sie das Kontrollkästchen Build Environment >> SSH Agent.
Wählen Sie die richtigen Anmeldeinformationen aus (wahrscheinlich die gleichen wie im Source Code ManagementAbschnitt ausgewählt

Aktualisieren Sie die Submodule im Execute ShellAbschnitt

git submodule sync
git submodule update --init --recursive

Hier ist ein Screenshot Geben Sie hier die Bildbeschreibung ein

— Potench
quelle

3

Es gibt kein solches Kontrollkästchen mehr.

— adi518

11

Es sieht so aus, als hätte ich eine Lösung gefunden:

Ich habe einen Build-Schritt hinzugefügt, um die folgenden Shell-Befehle auszuführen:

git submodule foreach git checkout master
git submodule foreach git pull

— Ben
quelle

Nachdem Sie diese Befehle ausgeführt haben, müssen Sie möglicherweise das Superprojekt festschreiben, da der HEAD in Ihren Submodulen aktualisiert wurde.

— Slacy

Hallo Ben, könnten Sie Ihre Lösung mit etwas mehr Details teilen? Ich möchte das Gleiche tun. Um nur zu bestätigen, aktualisiert Ihre Lösung die Submodule eines Projekts in den WORKSPACE, ja?

— Kim Stacks

Es gibt nicht viel mehr Details als das. Ich habe gerade diese 2 Zeilen zu meinem Erstellungsprozess hinzugefügt und es wird immer die neueste Version des Submoduls abgerufen.

— Ben

10

Wie @sti in einer anderen Antwort hier sagt, scheinen Sie zu versuchen, Git-Submodule wie SVN-Externals zu verwenden. Anstatt diese Befehle zu Jenkins hinzuzufügen, ist es besser, die richtigen Submodulversionen für Ihr Haupt-Git-Repo zu übernehmen. Jenkins überprüft dann immer die gleiche Version der Submodule, wenn eine bestimmte Version Ihres Projekts erstellt wird. Reproduzierbare Builds sind eine gute Sache.

— Cody Casterline

4

@ben Ich bin auf diesen Befehl gestoßen, den Sie vielleicht nützlicher finden, insbesondere wenn Sie den Hauptzweig im Submodul nicht verwenden git submodule update --init --recursive

— Corey Scott

7

Wenn Sie das Jenkins Git-Modul verwenden, können Sie es auf "Arbeitsbereich vor dem Erstellen löschen" setzen. Auf diese Weise erhält es immer das richtige Submodul.

— Amin Y.
quelle

2

Ich verwende Scripted Pipelining mit dem Checkout-Plugin. Wenn Sie möchten, dass die Submodule mit denen in Ihrem Repository identisch sind, deaktivieren Sie einfach die Option trackSubmodules wie folgt:

checkout([$class: 'GitSCM', branches: [[name: '*/develop']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: false, reference: '', trackingSubmodules: false]], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '[myCredentials]', url: 'https://git.myRepo.git']]])

— Jochen Gunzelmann
quelle