windows - Jenkins Error al clonar el repositorio remoto ''origen'', nodo esclavo

github slave

Question

Necesito ayuda aquí, ha pasado una semana con este problema, no puedo entender qué está pasando. No puedo clonar un repo de git de un nodo esclavo (Jenkins). Agregué la clave ssh, el host y el esclavo (ya he intentado generar una sola clave y una para cada virtual y host)).

En Jenkins:

• url: [email protected]: <repo>
• Credenciales: Aquí probé con nombre de usuario / contraseña, nombre de usuario con el archivo ssh, nombre de usuario con la clave ssh directamente y -none-.

No parece que haya un problema de autenticación ya que puedo clonar el repositorio manualmente desde la consola (tanto, esclavo como host). También me puedo conectar con

ssh -T [email protected]

entonces la clave ssh está bien, pero cuando construyo esto aparece en la consola:

Construcción remota en IE10Win7 en el área de trabajo C: / Users / IEUser / Desktop / <carpeta>

Borrando el espacio de trabajo primero.

Clonación del repositorio remoto de Git

Repositorio de clonación [email protected]: <repo> .git

git init C: / Users / IEUser / Desktop / <carpeta> # timeout = 10

ERROR: Error al clonar el repositorio remoto ''origen''

ERROR: Error al clonar el repositorio remoto ''origen''

Realizando la tarea de compilación Post ...

¿Alguien tiene alguna idea? Espero que alguien pueda darme una pista, ¡Gracias!

Answer 1

Encontré una solución decente en mi caso. El comando git clone siempre hereda el propietario del proceso, lo que puede hacer una diferencia, incluso si los dos propietarios de Jenkins (SYSTEM) y cmd (USER) parecen tener los mismos derechos en su sistema. Todas las demás configuraciones eran idénticas (claves, knownhosts, versión de cliente de Git).

Por lo que puedo ver, llamar a git clone desde cmd tendrá éxito porque llama al control remoto como USER, mientras que git clone llamado desde Jenkins puede ser rechazado porque llama al control remoto como SYSTEM. En Servicios, donde normalmente iniciaría Jenkins a través de la GUI, puede configurar el servicio para que se ejecute como un usuario diferente (haga clic con el botón secundario en Servicio -> Propiedades -> Iniciar sesión). Tuve que ponerlo como USER @ DOMAIN, por ejemplo, [email protected] o más. No estoy seguro de cómo se vería un parámetro cmd, pero espero que haya uno.

Además, no sé exactamente qué diferencia hace esta solución al final, porque en mi Jenkins, el SISTEMA y el USUARIO están configurados para tener los mismos derechos en todo el sistema y, por supuesto, ambos son reconocidos como "Jenkins" por control remoto. Aún así, funciona bien para mí. Conocimientos más profundos bienvenidos.

Answer 2

Recientemente actualicé varios plugins de jenkins y tuve este problema después de las actualizaciones. Retirar el plugin git no ayudó, pero hice algunas otras cosas para que funcione. Enumeré las tres aquí, pero probablemente (2) resolvió el problema. Aparentemente, el ejecutable git se restableció a los valores predeterminados. Entonces, la configuración del ejecutable git dentro del proyecto específico probablemente era todo lo que se necesitaba . Sin embargo, los otros elementos también pueden ser útiles.

(1) El git predeterminado en una instalación de jenkins linux apunta generalmente a / usr / lib ... Necesita especificar un GitForWindows separado que apunte a la versión de Windows:

Manage Jenkins
Configure System
Under Git - Git Installations
Add Git -> Git
Give it a name to be referenced in projects
(mine is WindowsGit)
Set Path to Git Executable
(mine is "C:/Program Files (x86)/Git/bin/git.exe")

(2) Configure git en el proyecto específico:

Select the project
Select Configure
Under Source Code Management - Git
Select Git Executable as configured in 1)
Set credentials or add new (ssh keys, etc)

(3) Actualizando el servicio esclavo Jenkins para ejecutar como un usuario específico:

Go to Windows Services on the slave -- StartMenu, type "services"
Select the Jenkins Slave service in the list on the right
Right-click and select "Properties" of the Jenkins Slave service
Select the "Log On" tab
Update the username and password used in manual tests
Domain login can be specificied with <DOMAIN>/<USERNAME>
Local logins just use <USERNAME>
OK to save and exit
Right-click again and select "Restart" to make the changes active.

Answer 3

Estaba enfrentando un problema similar y descubrí que necesito agregar git a la variable de entorno PATH para un esclavo basado en Windows. Creo que la sugerencia 2 de @dhj podría funcionar también en este caso.

Encontré esta solución en Jenkins Jira.

Answer 4

Resolví este problema estableciendo la ruta de la herramienta del nodo esclavo, seleccionando git y estableciendo su valor en

C:/Program Files (x86)/Git/bin/git.exe

Ubicación: configurar nodo: ubicaciones de herramientas

Answer 5

En mi caso, comencé a obtener este error exacto después de actualizar Git en algunas de mis máquinas de compilación (a través de Chocolatey, usando el paquete "git.install") de 1.9.4 a 2.5.0. La antigua instalación de 1.9.4 era un paquete de 32 bits, pero el nuevo es de 64 bits, por lo que la ubicación de instalación predeterminada cambió de C: / Archivos de programa (x86) / Git a C: / Program Files / Git. Tenía la ruta de 64 bits configurada en el maestro de Jenkins (ya que tenía la versión más nueva de Git), pero algunos esclavos aún tenían instalada la versión anterior de 32 bits, por lo que los esclavos estaban intentando utilizar una ruta incorrecta. Podría haber anulado la ruta de Git para esclavos individuales, pero la solución más limpia para mí fue simplemente actualizar todos los esclavos a la versión más nueva de 64 bits.

Answer 6

Intenté la mayoría de los anteriores:

Especifica la ubicación de git. Establecer usuario de servicio. Ejecutar como administrador.

Nada funcionó. Finalmente decidió desinstalar git64 e instalar git32 ... cambió la ruta de acceso de git a la nueva ubicación (en los archivos de programa x86). Y todo funcionó.

Answer 7

Me encontré con este problema recientemente.

Tuvimos algunos elementos en nuestro PATH EV que habíamos agregado al intentar conectar Winium y Selenium a nuestra instancia de Jenkins.

Eliminamos estos artículos, pero aún así Jenkins parecía estar aferrándose a los valores. Después de un poco de solución de problemas: reiniciar Jenkins; reiniciar el servidor de Jenkins; establecer los EV en el nivel del nodo; etc., reiniciamos el servicio Jenkins JNLP en el esclavo de Windows .

Y ellos vivieron felices para siempre.