Aktualizacja modułu submodule Jenkinsa kończy się niepowodzeniem.

Question

Mam repozytorium git z jednym modułem. Obaj należą do zespołu BitBucket. Mój komputer Jennkins to serwer Windows AWS z wtyczką git. Używam kluczy SSH do uwierzytelniania. Mam trzy prace Jenkins. Jeden klonuje główne repozytorium. To się udaje. Jeden klon sam drugi repozytorium (repo, które będzie używane jako submoduł). To również się udaje. W mojej trzeciej pracy polegającej na budowie, mówię jenkins, aby rekurencyjnie aktualizowały submoduły. To się nie powiedzie i mówi błąd klucza publicznego. Jak to się dzieje, jeśli mogę samodzielnie sklonować repo?

wyjście konsoli poniżej:

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 git@bitbucket.org:team/mainrepo.git 
> git.exe init C:\Program Files (x86)\Jenkins\jobs\mainrepo\workspace # timeout=10 
Fetching upstream changes from git@bitbucket.org:team/mainrepo.git 
> git.exe --version # timeout=10 
using GIT_SSH to set credentials 
> git.exe -c core.askpass=true fetch --tags --progress git@bitbucket.org:team/mainrepo.git +refs/heads/*:refs/remotes/origin/* 
> git.exe config remote.origin.url git@bitbucket.org: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 git@bitbucket.org:team/mainrepo.git # timeout=10 
Fetching upstream changes from git@bitbucket.org:team/mainrepo.git 
using GIT_SSH to set credentials 
> git.exe -c core.askpass=true fetch --tags --progress git@bitbucket.org: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 'git@bitbucket.org: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 'git@bitbucket.org: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 

Answer 1

Ten jest był znany błąd w Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-20941 ale został rozwiązany, zaktualizuj wtyczkę Git, aby rozwiązać ten problem.

Jeśli uaktualnienie nie jest możliwe, jako rozwiązanie tymczasowe można umieścić klucz w folderze .ssh użytkowników.

Answer 2

Jako alternatywę możesz użyć "Zarządzanie kodem źródłowym" - "Wiele modułów SCM", aby ręcznie skonfigurować wszystkie podmoduły i dodać "Dodatkowe zachowania" - "Sprawdź do podkatalogu" dla każdego z nich.

Answer 3

Wydaje się, że mają one ustalone to z wersjami git plugin klient 1.20.0-beta1 i git plugin 2.5.0-beta1. Jednak można je dodać tylko do Jenkinsa, określając, aby pobierać aktualizacje z eksperymentalnego centrum aktualizacji.

Answer 4

Na podstawie wcześniejszych odpowiedzi tutaj ponownie nadałem priorytet aktualizacji Jenkinsa mojego klienta. Teraz są na Jenkinsie 2.41 z wtyczką Git 3.0.1, a przed dodatkową konfiguracją nie rozwiązało to problemu. Znalazłem konfigurację być trochę trudne:

1. Dodaj repozytorium najwyższego poziomu Source Code Zarządzania -> Git
2. Wybrać „Dodatkowe Zachowania” przycisk Dodaj
   • Wybierz „Advanced podmodułów zachowania”
3. testowałem tylko«submodułów aktualizacji rekurencyjnie»i dostaliśmy«Permission denied»błąd (patrz dolny *)
4. jednak teraz wybrać zarówno „Rekurencyjnie aktualizuje submodules” i „Użyj poświadczeń z domyślnego pilota z repozytorium nadrzędnej” w Jenkins 2,41

Raz wybrać obie opcje, używa poświadczeń miałem skonfigurowane do repozytorium na najwyższym poziomie i wszystko działa na mnie. Oto co okno wygląda w 2,41 z Git plugin 3.0.1:

* Oto esencja mojego „Permission denied” Błąd:

Cloning into 'thirdparty'...

stderr: Permission denied (publickey). fatal: The remote end hung up unexpectedly Clone of 'ssh://hg@bitbucket.org//thirdparty' into submodule path 'thirdparty' failed

PS Tuż przed wysłaniem, odbyłem zwykłe podwójne sprawdzenie, aby upewnić się, że nie powielam odpowiedzi. W tym przypadku widzę, że komentarz @ danielfn wskazuje na coś, co jest prawie identyczne z moją odpowiedzią, ale 1. to mi nie pomogło i doszedłem do wniosku, że jest to próbą i błędem i 2. jest to polityka StackOverflow do publikowania odpowiedzi tutaj, zamiast odwoływania się do zewnętrznych linków.