La actualización del submodule git de Jenkins falla

Tengo un repository git que tiene un submodule. Ambos pertenecen a un equipo en BitBucket. Mi máquina jenkins es un server de Windows AWS con el plugin git. Estoy usando keys SSH para la authentication. Tengo tres trabajos de Jenkins. Uno clona el repository principal. Esto es exitoso Uno clona el segundo repository por sí mismo (el repository que se usará como submodule). Esto también es exitoso. En mi tercer trabajo de construcción le digo a Jenkins que actualice recursivamente los submodules. Esto falla y dice error de key pública. ¿Cómo puede ser este el caso si puedo clonar el repository por sí mismo?

Salida de la console a continuación:

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 cnetworkingentials > 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 cnetworkingentials > 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 

Este es un error conocido en jenkins: https://issues.jenkins-ci.org/browse/JENKINS-20941 pero ahora se ha solucionado, actualice su plugin de Git para resolver el problema.

Si la actualización no es posible, como solución alternativa, puede colocar la key en la carpeta jenkins-users .ssh.

En function de las respuestas anteriores, volví a priorizar la actualización de Jenkins de mi cliente. Ahora están en Jenkins 2.41 con Git plugin 3.0.1 y antes de la configuration adicional esto no solucionó el problema. Encontré la configuration un poco complicada:

  1. Agregue un repository de nivel superior a Source Code Management -> Git
  2. Seleccione el button Agregar "Comportamientos adicionales"
    • Seleccione "Comportamientos avanzados de submodules"
  3. Probé solo con "Submodules de actualización recursiva" y recibí el error "Permiso denegado" (ver abajo *)
  4. Sin embargo, ahora selecciono tanto "Submodules de actualización recursiva" como "Usar cnetworkingenciales del remoto pnetworkingeterminado del repository principal" en Jenkins 2.41

Una vez que selecciono ambas opciones, usa las cnetworkingenciales que había configurado para el repository de nivel superior y todo funciona para mí. Este es el aspecto del dialog en 2.41 con Git plugin 3.0.1: Configuración de autenticación de submódulo git bajo Jenkins 2.41

* Aquí está la esencia de mi error "Permiso denegado":

Clonación en 'tercera parte' …

stderr: Permiso denegado (key pública). fatal: el extremo remoto colgó inesperadamente El clon de 'ssh: //hg@bitbucket.org//thirdparty' en la ruta del submodule 'thirdparty' falló

PD Justo antes de publicar, hice mi doble verificación habitual para asegurarme de no estar duplicando una respuesta. En este caso, veo que el comentario de @ danielfn apunta a algo que es casi idéntico a mi respuesta, pero 1. esto no me ayudó y terminé averiguando por ensayo y error y 2. es la política de StackOverflow para publicar responde aquí en lugar de hacer reference a enlaces externos.

Parece que lo han solucionado con las versiones de git client plugin 1.20.0-beta1 y git plugin 2.5.0-beta1 . Sin embargo, solo se pueden agregar a Jenkins al especificar extraer actualizaciones del centro de actualización experimental.

Como alternativa, puede usar 'Source Code Management' – 'Multiple SCMs' para configurar manualmente todos los submodules y agregar 'Behaviors Adicionales' – 'Check out a un subdirectory' para cada uno.