Aktualisierung des Jenkins-Git-Submoduls schlägt fehl

Lesezeit: 5 Minuten

Ich habe ein Git-Repo mit einem Submodul. Beide gehören zu einem Team auf BitBucket. Meine Jenkins-Maschine ist ein AWS-Windows-Server mit dem Git-Plugin. Ich verwende SSH-Schlüssel zur Authentifizierung. Ich habe drei Jenkins-Jobs. Man klont das Hauptrepo. Das ist erfolgreich. Man klont das zweite Repo allein (das Repo, das als Submodul verwendet wird). Auch das gelingt. In meinem dritten Build-Job weise ich jenkins an, die Submodule rekursiv zu aktualisieren. Dies schlägt fehl und zeigt einen Public-Key-Fehler an. Wie kann das der Fall sein, wenn ich das Repo alleine klonen kann?

Konsolenausgabe unten:

Started by user anonymous
Building on master in workspace C:\Program Files (x86)\Jenkins\jobs\MainRepo\workspace
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository [email protected]:team/mainrepo.git
 > git.exe init C:\Program Files (x86)\Jenkins\jobs\mainrepo\workspace # timeout=10
Fetching upstream changes from [email protected]:team/mainrepo.git
 > git.exe --version # timeout=10
using GIT_SSH to set credentials 
 > git.exe -c core.askpass=true fetch --tags --progress [email protected]:team/mainrepo.git +refs/heads/*:refs/remotes/origin/*
 > git.exe config remote.origin.url [email protected]:team/mainrepo.git # timeout=10
 > git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git.exe config remote.origin.url [email protected]:team/mainrepo.git # timeout=10
Fetching upstream changes from [email protected]:team/mainrepo.git
using GIT_SSH to set credentials 
 > git.exe -c core.askpass=true fetch --tags --progress [email protected]:team/mainrepo.git +refs/heads/*:refs/remotes/origin/*
 > git.exe rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
 > git.exe rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
Checking out Revision 6b3f6535c45e79ee88f4918d464edead48d83369 (refs/remotes/origin/master)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 6b3f6535c45e79ee88f4918d464edead48d83369
 > git.exe rev-list 6b3f6535c45e79ee88f4918d464edead48d83369 # timeout=10
 > git.exe remote # timeout=10
 > git.exe submodule init # timeout=10
 > git.exe submodule sync # timeout=10
 > git.exe config --get remote.origin.url # timeout=10
 > git.exe submodule update --init --recursive
FATAL: Command "git.exe submodule update --init --recursive" returned status code 128:
stdout: 
stderr: Cloning into 'my-submodule'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of '[email protected]:team/my-submodule.git' into submodule path 'my-submodule' failed

hudson.plugins.git.GitException: Command "git.exe submodule update --init --recursive" returned status code 128:
stdout: 
stderr: Cloning into 'my-submodule'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: clone of '[email protected]:team/my-submodule.git' into submodule path 'my-submodule' failed

    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:62)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$7.execute(CliGitAPIImpl.java:953)
    at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:90)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1098)
    at hudson.scm.SCM.checkout(SCM.java:485)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
    at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
    at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
    at hudson.model.Run.execute(Run.java:1738)
    at hudson.matrix.MatrixBuild.run(MatrixBuild.java:301)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:410)
Finished: FAILURE

  • Verwenden Sie für alle drei Jobs dieselben Jenkins-Anmeldeinformationen? Laufen sie alle auf derselben AWS-Instanz? Und verwenden Sie dasselbe Benutzerkonto, um die Git-Befehle in allen drei Jobs auszuführen? Ich sehe, dass der fehlgeschlagene Job das “anonyme” Konto verwendet.

    – gareth_bowles

    10. Februar 2016 um 16:44 Uhr

  • Ja, alle auf derselben AWS-Instanz. Alle verwenden die gleichen SSH-Schlüsselanmeldeinformationen. Ich habe keine Benutzerkonten eingerichtet, nur ich benutze es im Moment.

    – Tomcheney

    10. Februar 2016 um 16:45 Uhr

Basierend auf den früheren Antworten hier habe ich das Upgrade des Jenkins meines Clients neu priorisiert. Jetzt sind sie auf Jenkins 2.41 mit Git-Plugin 3.0.1 und vor der zusätzlichen Konfiguration hat dies das Problem nicht behoben. Etwas fummelig fand ich die Konfiguration:

  1. Repository der obersten Ebene zu Source Code Management -> Git hinzufügen
  2. Wählen Sie die Schaltfläche “Zusätzliche Verhaltensweisen” Hinzufügen
    • Wählen Sie “Erweitertes Untermodulverhalten”
  3. Ich habe nur mit “Recursively update submodules” getestet und den Fehler “Permission denied” erhalten (siehe unten *)
  4. Allerdings wähle ich jetzt in Jenkins 2.41 sowohl „Recursively update submodules“ als auch „Use Credentials from Default Remote of Parent Repository“ aus

Sobald ich beide Optionen auswähle, verwendet es die Anmeldeinformationen, die ich für das Repository der obersten Ebene konfiguriert hatte, und alles funktioniert für mich. So sieht der Dialog in 2.41 mit dem Git-Plugin 3.0.1 aus:
git-Submodul-Authentifizierungskonfiguration unter Jenkins 2.41

* Hier ist die Essenz meines Fehlers “Zugriff verweigert”:

Klonen in ‘Drittanbieter’…

stderr: Berechtigung verweigert (Publickey). fatal: Das Remote-Ende hat unerwartet aufgelegt Klonen von „ssh://[email protected]//thirdparty“ in den Submodulpfad „thirdparty“ fehlgeschlagen

PS Kurz vor dem Posten habe ich meine übliche Doppelprüfung durchgeführt, um sicherzustellen, dass ich keine Antwort dupliziere. In diesem Fall sehe ich, dass der Kommentar von @danielfn auf etwas verweist, das fast identisch mit meiner Antwort ist, aber 1. das hat mir nicht geholfen und ich habe es schließlich durch Versuch und Irrtum herausgefunden, und 2. es ist die StackOverflow-Richtlinie zum Posten Antworten hier, anstatt auf externe Links zu verweisen.

Alternativ können Sie „Quellcodeverwaltung“ – „Mehrere SCMs“ verwenden, um alle Untermodule manuell zu konfigurieren, und „Zusätzliche Verhaltensweisen“ – „In ein Unterverzeichnis auschecken“ für jedes hinzufügen.

Benutzer-Avatar
danielfn

Es scheint, dass sie es mit den Versionen behoben haben Git-Client-Plugin 1.20.0-beta1 und Git-Plugin 2.5.0-beta1. Sie können jedoch nur zu Jenkins hinzugefügt werden, indem angegeben wird, dass Updates aus dem experimentellen Update-Center abgerufen werden sollen.

  • Ich habe auf das Git-Client-Plugin 1.21.0 und das Git-Plugin 2.5.3 aktualisiert, aber nichts hat sich geändert. Ich vermisse etwas?

    – dknaack

    26. August 2016 um 11:21 Uhr

  • Haben Sie den Abschnitt “Advanced Submodules Behaviour” richtig konfiguriert? Sehen Sie sich die Anweisungen an in diesem Kommentar aus ihrem Issue-Tracker.

    – danielfn

    27. August 2016 um 14:15 Uhr

  • Ja, habe ich. Ich habe jetzt auf das Git-Client-Plugin 2.0.0-beta4 aktualisiert, um mein Problem zu lösen.

    – dknaack

    27. August 2016 um 14:36 ​​Uhr

1054140cookie-checkAktualisierung des Jenkins-Git-Submoduls schlägt fehl

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy