it-swarm.com.de

Jenkins: Submodule mit Git abrufen

Momentan bin ich bei einem Problem geblieben, bei dem versucht wurde, die Submodule eines Repositorys aus Jenkins abzurufen. Meine Konfiguration ist in Ordnung und ich kann Repositories ohne Submodule problemlos abrufen. 

Ich kann auch die Hauptkomponenten eines Repos mit Submodulen ziehen (beide mit Authentifizierung im Repository-Namen wie bei SSH). Das Problem tritt nur auf, wenn ich die Submodulkomponenten ziehen muss. Ich führe die neueste Version von Jenkins aus und habe unten einen Teil hinzugefügt, der für "Verhalten der erweiterten Submodule" gedacht ist. Ich habe hier "Rekursives Update der Submodule" ausgewählt und den Build mehrmals ohne Erfolg ausgeführt.

Wenn ich versuche, unten mit Shell-Befehlen einen zusätzlichen Build-Schritt hinzuzufügen, funktioniert die Aktualisierung der Repositorys ebenfalls nicht. Wenn ich diese Befehle außerhalb von Jenkins in meinem Terminal versuche, funktioniert das einwandfrei. Das Thema, das ich immer in Jenkins bekomme, lautet: 

FATAL: Command "git submodule update" returned status code 1:

stdout: 

stderr: Cloning into 'thisismysubmodule'...
fatal: Authentication failed for 'https://git.thisismyrepo.com/scm/ap/thisismysubmodule.git/'

Ich habe dieses Problem gefunden: https://issues.jenkins-ci.org/browse/JENKINS-20941 , aber ich kann die vorgeschlagene Lösung aus Sicherheitsgründen nicht verwenden. Hat hier jemand Erfahrung mit diesem Problem oder einer möglichen Lösung?

21
ItWillDo

Hier ist eine Problemumgehung mithilfe von SSH Agent Forwarding . Es hat gut für mich funktioniert.

  1. Bearbeiten Sie zuerst <jenkins_home>/.ssh/config und setzen Sie ForwardAgent yes
  2. Installieren Sie dann SSH Agent Plugin für Jenkins.
  3. Setzen Sie dann in der Projektkonfiguration die Git-Anmeldeinformationen zurück.
  4. Legen Sie schließlich in der Projektkonfiguration den Berechtigungsnachweis für den SSH-Agenten fest.

enter image description hereSSH Agent settings in Jenkins project configuration

13
Benoit Blanchon

Um dieses Problem zu lösen, wurden jetzt Betaversionen der Module git-client und git-plug-in veröffentlicht. Um das JIRA-Problem zu zitieren.

Das git Client Plugin 2.0.0-beta1 wurde auf der .__ veröffentlicht. experimentelles Update-Center. Es beinhaltet die Authentifizierung des Submoduls von git JGit 4.3 und erfordert JDK 7. Es erfordert mindestens Jenkins 1.625 (die Erste Version, um JDK 7 zu bestellen).

Wenn Sie das oben genannte verwenden, gibt es im Abschnitt Zusätzliche Verhalten eine Option mit dem Namen:

Verwenden Sie die Anmeldeinformationen aus dem Standard-Remote des übergeordneten Repositorys

Dies behebte mein Problem bei der Verwendung von Jenkins 2.11 und den Betaversionen des Plug-Ins, auf dem ein Windows-Server und ein Slave ausgeführt werden. Ich habe andere Build-Maschinen nicht geprüft. Außerdem müssen Sie dieselbe Authentifizierungsmethode verwenden. Wenn Sie HTTP verwenden, müssen Sie auch die Submodule verwenden. Wenn Sie SSH verwenden, müssen Sie dies für die Submodule verwenden korrekt.

- UPDATE -
Betaversionen werden nicht mehr benötigt, siehe folgende Seiten:
Git Client Plugin
Git Plugin

7
JamesD

Ich habe es gerade zu einem Shell-Befehl verschoben und im Shell-Befehl habe ich gesagt, welche Helfer für Anmeldeinformationen verwendet werden sollen, da ich unter Windows bin, wurde es wincred:

git config --global credential.helper wincred
git submodule init 
git submodule sync 
git submodule update --init --recursive
1

Eine Lösung wäre, in der globalen git-Konfigurationsdatei eine Hilfe für netrc-Berechtigungsnachweise zu deklarieren, die die erforderlichen Berechtigungsnachweise für jede von git stammende http-Abfrage bereitstellt. 

git config --global credential.helper "netrc -f C:/path/to/_netrc.gpg -v"

(Stellen Sie sicher, dass Sie dasselbe Konto verwenden, das für das Ausführen von Jenkins verwendet wird.)

Ich benutze eine verschlüsselte netrc-Datei , aber Sie können einen Test mit einer unverschlüsselten starten.

1
VonC

In Anbetracht dessen, dass ich so ziemlich alle verfügbaren Optionen ausprobiert habe (SSH, .netrc, fest codierte Anmeldeinformationen, ...), war die einzige Option diejenige, die am Ende der JENKINS-20941-Ausgabe von 'andreg' erwähnt wurde:

Ja, diese Ausgabe ist auch für uns ein schmerzlicher Schmerz. Der einzige Weg, wie wir es schaffen könnten. Für unser Stash/Jenkins-Setup funktionierte es, einen schreibgeschützten Benutzer zu erstellen und um die Anmeldeinformationen dieses Benutzers in der Referenz auf .__ fest zu codieren. Submodul. Obwohl es eine schlechte Praxis ist, arbeiten alle Benutzer, die am git-Repo arbeiten haben zumindest Lesezugriff, so dass wir nicht das Gefühl hatten. viel Sicherheitsbedenken. z.B. in der übergeordneten Repo-.gitmodules-Datei:

[Untermodul "shared-library"] path = URL der gemeinsam genutzten Bibliothek = https: // benutzername: [email protected]/scm/project/shared-library.git

und dann hat der Jenkins-Job die Option "Submodule rekursiv aktualisieren" ausgewählt.

1
ItWillDo

Ich habe es geschafft, dies zu erreichen, indem ich einfach eine .netrc-Datei mit den Anmeldeinformationen für Linux hinzufügte. Nicht die sicherste Lösung, aber wenn Sie es schnell zum Laufen bringen wollen, wird es Sie in Schwung bringen.

0
math0ne

Diese Lösung hat für mich funktioniert:

  1. Stellen Sie sicher, dass die ssh-Berechtigungsnachweise für das übergeordnete Repo und das Submodul-Repo identisch sind.
  2. Richten Sie die Berechtigungsnachweise für das übergeordnete Repo in Jenkins ein. (Quellcodeverwaltung (wählen Sie "Git")> Repositorys)
  3. Richten Sie Ihre .gitmodule-Datei so ein, dass sie die ssh-Berechtigungsnachweise aus dem übergeordneten Repo verwendet:

    [submodule "foo/repository"]
       path = foo/repository
       url = ssh://[email protected]/repository
    
  4. Bei dieser Lösung gibt es einen kleinen Vorbehalt. Immer wenn jemand das übergeordnete Repo klont, muss er die URL mit einer URL synchronisieren, auf die er Zugriff hat. Wenn ein Benutzer das Submodul zum ersten Mal initialisiert, muss er zuerst die .gitmodules-Datei bearbeiten und die URL ändern:

    [submodule "foo/repository"]
       path = foo/repository
       url = ssh://[email protected]/repository
    

    Dann im Terminal:

    git submodule sync
    git submodule init repository
    git submodule update --remote repository
    

    Und dann ändern Sie die URL wieder in die Jenkins-Build-URL. Wenn Sie nicht erneut synchronisieren, verwendet das Submodul die dem Benutzer zugeordnete URL.

Im September 2016 plant Jenkins eine neue Funktion, mit der Submodule die Berechtigungsnachweise des übergeordneten Repositorys gemeinsam nutzen können. Dann kann eine HTTP-URL in .gitmodule anstelle von ssh verwendet werden.

0
sdw