Errore Jenkins clonazione repo remoto 'origine', nodo slave

Question

Ho bisogno di aiuto qui, è stata una settimana sono con questo problema, non riesco a capire cosa sta succedendo. Non sono in grado di clonare un repository git da un nodo slave (Jenkins). Ho aggiunto la chiave ssh, host e slave (ho già provato a generare una singola chiave e una per ogni virtual e host)).

Su Jenkins:

• url: git@github.com: < repo>
• Credenziali: Qui ho provato con nome utente/password, nome utente con il file ssh, il nome utente con chiave SSH direttamente, e - nessuna-.

Non sembra che ci sia un problema di autenticazione dal momento che posso clonare il repository manualmente dalla console (sia slave che host). Posso anche collegare con

ssh -T git@github.com

così la chiave ssh va bene, ma quando ho costruire, questo apparire su console:

Building remotely on IE10Win7 in workspace C:\Users\IEUser\Desktop\< folder >

Wiping out workspace first.

Cloning the remote Git repository

Cloning repository git@github.com:< repo>.git

git init C:\Users\IEUser\Desktop\< folder> # timeout=10

ERROR: Error cloning remote repo 'origin'

ERROR: Error cloning remote repo 'origin'

Performing Post build task...

Qualcuno ha un'idea? Spero che qualcuno possa darmi un indizio, grazie!

Answer 1

Ho trovato una soluzione decente nel mio caso. Il comando git clone eredita sempre il proprietario del processo, il che può fare la differenza, anche se i due proprietari di Jenkins (SYSTEM) e cmd (USER) sembrano avere gli stessi diritti sul sistema. Tutte le altre configurazioni erano identiche (chiavi, knownhosts, versione client Git).

Quindi, per quanto posso vedere, chiamando git clone da cmd avrà successo perché richiede il telecomando come USER, mentre git clone chiamato da Jenkins può essere respinta perché richiede il telecomando come SYSTEM. Nei Servizi, in cui normalmente avvii Jenkins tramite la GUI, puoi configurare il servizio in modo che venga eseguito come utente diverso (fai clic con il pulsante destro del mouse su servizio -> Proprietà -> Accedi). Ho dovuto metterlo come USER @ DOMAIN, ad es. Jenkins@company.local o così. Non sono sicuro di come apparirà un parametro cmd, ma mi aspetto che ce ne sia uno.

Inoltre, non so quale differenza questa soluzione fa alla fine, perché su Jenkins, SYSTEM e USER sono configurati per avere gli stessi diritti su tutto il sistema e sono entrambi riconosciuti come "Jenkins" da remoto. Eppure, fa il trucco per me. Approfondimenti più approfonditi.

Answer 2

Recentemente ho aggiornato diversi plugin di jenkins e ho avuto questo problema dopo gli aggiornamenti. Rollback del plugin git non ha aiutato, ma ho fatto un paio di altre cose per farlo funzionare. Ho elencato tutti e tre qui, ma era probabilmente (2) che ha risolto il problema. Apparentemente il git eseguibile è stato ripristinato al valore predefinito. Quindi, la configurazione del git eseguibile all'interno del progetto specifico era probabilmente tutto ciò che era necessario. Tuttavia anche gli altri oggetti potrebbero tornare utili.

(1) Il git predefinito su un'installazione jenkins di Linux punta geenrally su/usr/lib ...È necessario specificare un GitForWindows separati che punta alla versione di 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) Configurare git sul progetto specifico:

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) Aggiornamento del servizio di Jenkins schiavi per l'esecuzione come utente specifico:

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

Mi trovavo di fronte a un problema simile e ho scoperto che ho bisogno di aggiungere git alla mia variabile di ambiente PATH per uno slave basato su Windows. Penso che @dhj suggerimento 2 possa funzionare anche in questo caso.

ho trovato questa soluzione su Jenkins Jira.

Answer 4

ho risolto questo problema impostando il percorso utensile nodo slave, selezionando git e impostando il suo valore a

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

Località: Configurazione nodo - Luoghi strumento

Answer 5

Nel mio caso, ho iniziato a ricevere questo errore esatto dopo aver aggiornato Git su un po 'di delle mie macchine di compilazione (tramite Chocolatey, utilizzando il pacchetto "git.install") dalla 1.9.4 alla 2.5.0. La vecchia installazione 1.9.4 era un pacchetto a 32 bit, ma il nuovo è uno a 64 bit, quindi il percorso di installazione predefinito è passato da C: \ Programmi (x86) \ Git a C: \ Programmi \ Git. Avevo il percorso a 64 bit configurato sul master Jenkins (dato che aveva la versione Git più recente), ma alcuni slave avevano ancora la vecchia versione a 32 bit installata, quindi gli slave stavano tentando di usare un percorso errato. Avrei potuto scavalcare il percorso Git per singoli slave ma la soluzione più pulita per me era semplicemente aggiornare tutti gli slave alla nuova versione a 64 bit.

Answer 6

Ho provato la maggior parte di quanto sopra:

Specifica posizione git. Imposta utente servizio. Esegui come amministratore.

Nessuno dei due ha funzionato. Alla fine ha deciso di disinstallare git64 e installare git32 ... ha cambiato il percorso git nella nuova posizione (in Programmi x86). E tutto ha funzionato.

Answer 7

Ho riscontrato di recente questo problema.

Avevamo alcuni elementi nel nostro PATH EV che avevamo aggiunto durante il tentativo di connettere Winium e selenio alla nostra istanza Jenkins.

Abbiamo rimosso questi articoli, ma Jenkins sembrava mantenere i valori. Dopo un po 'di risoluzione dei problemi: riavvio di Jenkins; riavvio del server Jenkins; impostare gli EV a livello di nodo; ecc., abbiamo riavviato il servizio JNLP di Jenkins sullo slave Windows.

E vissero felici e contenti.