submodulos - git tag commit id

Jenkins: recuperando submódulos con Git (7)

Aquí hay una solución alternativa utilizando el reenvío de agente SSH . Funcionó bien para mí.

Primero, edite <jenkins_home>/.ssh/config y establezca ForwardAgent yes
Luego, instale el plugin SSH Agent para Jenkins.
Luego, en la configuración del proyecto, restablece las credenciales de Git.
Finalmente, en la configuración del proyecto, configure la credencial del Agente SSH.

Actualmente me he quedado atascado en un problema al intentar recuperar los submódulos de un repositorio desde Jenkins. Mi configuración está bien y puedo extraer repositorios sin ningún submódulo muy bien.

También puedo extraer los componentes principales de un repositorio con submódulos (tanto con autenticación en el nombre del repositorio como con SSH). El problema solo surge cuando tengo que tirar de los componentes del submódulo. Estoy ejecutando la última versión de Jenkins y he agregado una parte en la parte inferior que es para "Comportamientos de submódulos avanzados". Seleccioné "Actualizar de forma recursiva los submódulos" aquí y ejecuté la compilación varias veces sin éxito.

Cuando intento agregar un paso de compilación adicional en la parte inferior con comandos de shell, la actualización de los repositorios tampoco funciona. Cuando intento estos comandos fuera de jenkins en mi terminal, esto funciona bien. El problema que siempre tengo en Jenkins es:

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/''

He encontrado este problema: https://issues.jenkins-ci.org/browse/JENKINS-20941 pero no puedo usar la solución sugerida en la parte inferior debido a problemas de seguridad. ¿Alguien aquí tiene alguna experiencia con este problema o una posible solución?

De hecho, simplemente lo moví a un comando de shell y en el comando de shell le dije qué credenciales de ayudante usar, ya que estoy en Windows, estaba en Wincred:

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

Esta solución funcionó para mí:

Asegúrese de que las credenciales ssh sean las mismas para el repositorio principal y el repositorio de submódulo.
Configurar credenciales para el repositorio de los padres en Jenkins. (Gestión de código fuente (seleccione "Git")> Repositorios)
Configure su archivo .gitmodule para que use las credenciales ssh del repositorio principal:
[submodule "foo/repository"] path = foo/repository url = ssh://[email protected]/repository
Hay una pequeña advertencia a esta solución. Cada vez que alguien clone el repositorio principal, deberá sincronizar la URL con una a la que tenga acceso. La primera vez que un usuario inicializa el submódulo, primero debe editar el archivo .gitmodules y cambiar la url:
[submodule "foo/repository"] path = foo/repository url = ssh://[email protected]/repository
Luego, en la terminal:
git submodule sync git submodule init repository git submodule update --remote repository
Y luego cambie la url de nuevo a la url de compilación de jenkins. A menos que se vuelva a sincronizar, el submódulo usará la url asociada con el usuario.

En septiembre de 2016, Jenkins planea lanzar una nueva función que permitirá a los submódulos compartir las credenciales del repositorio principal. Luego se puede usar una url HTTP en .gitmodule en lugar de ssh.

Logré que esto funcionara simplemente agregando un archivo .netrc con las credenciales en Linux. No es la solución más segura, pero si necesita que funcione rápidamente, podrá hacerlo.

Se han lanzado versiones beta de los módulos git-client y git-plug-in para resolver este problema. Para citar el tema JIRA.

El complemento de cliente git 2.0.0-beta1 se ha lanzado al centro de actualización experimental. Incluye la autenticación de submódulos de git, JGit 4.3, y requiere JDK 7. Requiere al menos Jenkins 1.625 (la primera versión que exige JDK 7)

Usando lo anterior hay una opción en la sección Comportamientos adicionales llamada:

Usar credenciales del remoto predeterminado del repositorio principal

Esto resolvió mi problema al usar Jenkins 2.11 y las versiones beta del complemento que ejecutan un servidor y esclavo de Windows. No he comprobado otras maquinas de compilación. También debe usar el mismo método de autenticación. Si usa http, también debe usarlo para los submódulos. Si usa SSH, debe usar esto para los submódulos. Tratar de mezclar métodos no funcionará correctamente.

- ACTUALIZACIÓN -
Las versiones Beta ya no son necesarias, consulte las siguientes páginas:
Complemento de cliente Git
Plugin Git

Teniendo en cuenta que he probado prácticamente todas las opciones disponibles para que esto funcione (SSH, .netrc, credenciales codificadas, ...), la única opción fue la que se mencionó en la parte inferior de la edición de JENKINS-20941 de ''andreg''

Sí, este problema es un verdadero dolor para nosotros también. La única forma en que pudimos hacerlo funcionar para nuestra configuración de Stash / Jenkins fue crear un usuario de solo lectura y codificar las credenciales de este usuario en la referencia al submódulo. Aunque es una mala práctica, todos los usuarios que trabajan en el repositorio de git ya tienen acceso de solo lectura, por lo que no sentimos que sea un problema de seguridad. Por ejemplo, en el archivo .gitmodules del repositorio principal:
[submódulo "biblioteca-compartida"] ruta = biblioteca-compartida url = https://username:[email protected]/scm/project/shared-library.git
y luego el trabajo de Jenkins tiene seleccionado "Actualizar de forma recursiva los submódulos".

Una solución sería declarar en el archivo de configuración global de git una ayuda de credenciales netrc, que proporcionaría las credenciales necesarias para cualquier consulta http proveniente de git.

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

(Asegúrese de usar la misma cuenta que la que se usa para ejecutar Jenkins)

Utilizo un archivo netrc encriptado , pero puede comenzar alguna prueba con uno no encriptado.