2012-10-30 10 views
8

Ich habe einen Jenkins-Build, der eine Capistrano-Bereitstellung als Post-Build-Aktion ausführt.Bereitstellen über Capistrano über Jenkins - SSH-Authentifizierung fehlgeschlagen

Das Ausführen der Capistrano-Aufgabe als Jenkins-Benutzer von der Konsole funktioniert absolut gut und ohne eine Kennworteingabeaufforderung (Ich habe zuvor SSH-Schlüssel auf Build- und Staging-Server eingerichtet). Wenn ich jedoch das gleiche Skript über Jenkins laufen lasse, bekomme ich plötzlich eine Passwortabfrage und der Build schlägt anschließend fehl (kein TTY vorhanden).

[workspace] $ /bin/sh -xe /tmp/hudson7321493219694918714.sh 
Performing Post build task... 
Match found for : : True 
Logical operation result is TRUE 
Running script : cap _2.13.4_ deploy 
[workspace] $ /bin/sh -xe /tmp/hudson1545664641721322948.sh 
+ cap _2.13.4_ deploy 
    * executing `deploy' 
    * executing `deploy:update' 
** transaction: start 
    * executing `deploy:update_code' 
    triggering before callbacks for `deploy:update_code' 
[32m--> Updating code base with checkout strategy[0m 
    executing locally: "git ls-remote [email protected]:my_project.git master" 
    command finished in 1200ms 
    * executing "git clone -q [email protected]:my_project.git /var/www/staging/my_project/releases/20121029223619 && cd /var/www/staging/my_project/releases/20121029223619 && git checkout -q -b deploy 1fb11d669a6cb5a714d077162305dfcfaba82f01 && (echo 1fb11d669a6cb5a714d077162305dfcfaba82f01 > /var/www/staging/my_project/releases/20121029223619/REVISION)" 
servers: ["my.staging-server.com"] 
Password: stty: standard input: Inappropriate ioctl for device 
stty: standard input: Inappropriate ioctl for device 
stty: standard input: Inappropriate ioctl for device 

*** [deploy:update_code] rolling back 
    * executing "rm -rf /var/www/staging/my_project/releases/20121029223619; true" 
    servers: ["my.staging-server.com"] 
** [deploy:update_code] exception while rolling back: Capistrano::ConnectionError, connection failed for: my.staging-server.com (Net::SSH::AuthenticationFailed: not-specified) 
connection failed for: my.staging-server.com (Net::SSH::AuthenticationFailed: not-specified) 
POST BUILD TASK : FAILURE 

Es sieht aus wie Ruby nicht meine SSH-Schlüssel abholen, wenn vielleicht durch Jenkins läuft (Net::SSH::AuthenticationFailed: not-specified)?

Hat jemand eine Idee, was hier schief gehen könnte?

+0

Das gleiche Shell-Skript auszuführen, das Jenkins im Projektarbeitsbereich als Benutzer jenkins in /tmp/hudson*.sh generiert, funktioniert einwandfrei. Was auch seltsam ist, ist, dass SSH'ing zum Server gut funktioniert, aber das Klonen von git (Git-Server auf demselben entfernten Rechner als Build-Ziel) scheitert (nur wenn es in Jenkins-Build ausgeführt wird). Ich bin verwirrt. – Burgi

+0

Ich denke, Jenkins läuft als "root", also legen Sie ein "env | sort" in Ihr Skript vor dem "cap" -Befehl, damit es die Umgebungsinformationen ausgibt, damit Sie sehen können, wer der Benutzer ist. Ich arbeite jetzt an demselben Problem. Ich werde dich wissen lassen, wenn ich mir was einfallen lasse. – Harmon

+1

Mit welchem ​​Benutzer verbindet sich Ihr Capistrano-Skript? Möglicherweise wird der "Git-Klon" als anderer Benutzer ausgeführt, wenn Sie nicht angeben, mit wem Sie eine Verbindung herstellen möchten. Es wird standardmäßig für den Benutzer verwendet, der das Cap-Skript vom Bereitstellungshost ausführt. Dies ist zum Beispiel unser Setup: 'server '# {deploy_user} @ # {hostname}",: app,: db,: primary => true' und 'set: deploy_user, ENV [' USER ']'. – Harmon

Antwort

5

Wir etwas lief in ähnlichen dies. Es ist möglich, dass die Login-Shell für jenkins bereits einen SSH-Agenten hat, der automatisch ausgeführt wird, aber der Kontext, den jenkins für Ihre Bereitstellung erzeugt, funktioniert nicht.

Versuchen Sie eine manuell in Ihrem jenkins Skript starten:

# Start the ssh agent. Evaling the output will set the relevant environment 
# variables 
eval `ssh-agent` 

# Add the default keys like id_rsa and id_dsa (or explicitly specify your key, 
# if it's not a default) 
ssh-add 

# Your normal deploy script here 

# Save the return value of your script 
RETVAL=$? 

# Clean up 
kill $SSH_AGENT_PID 

# Exit the script with the true return value instead of the return value of kill 
# which could be successful even when the capistrano portion of the build has 
# crashed 
exit $RETVAL 

Hoffnung dies für Sie arbeitet! Muscheln sind nervig.

+0

Das hat es behoben. Vielen Dank! –

0

Leider aufgelöst ich es nur durch original deploy.rb ersetzen, bevor cap deploy mit einem anderen lokal gespeicherten Ausführung, wo ich set :password, "sshpassword" hinzugefügt