2012-10-30 16 views
8

ビルド後のアクションとしてCapistranoを実行するJenkinsビルドがあります。JenkinsによるCapistrano経由のデプロイ - SSH認証に失敗しました

コンソールからJenkinsユーザーとしてCapistranoタスクを実行すると、パスワードのプロンプトが表示されずに正常に機能します(以前はビルドサーバーとステージングサーバーの両方でSSHキーを設定していました)。しかし、Jenkinsから同じスクリプトを実行すると、私は突然パスワードのプロンプトを表示し、ビルドは失敗します(TTYは存在しません)。

[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 

おそらくジェンキンス通過するとき、それは私のSSHキーをピックアップしませんルビーのように見えます(Net::SSH::AuthenticationFailed: not-specified)?

誰かがここで間違っているかもしれないアイデアはありますか?

+0

Jenkinsがプロジェクトのワークスペース内の/tmp/hudson*.shで生成する、まったく同じシェルスクリプトを、ユーザーjenkinsとして実行すると完全に正常に動作します。奇妙なのは、サーバーへのSSH接続は正常に動作しますが、git(ビルドターゲットと同じリモートマシン上のgitサーバー)からのクローン作成は失敗します(Jenkinsビルドで実行した場合のみ)。よくわかりません。 – Burgi

+0

私はJenkinsが "root"として実行されていると思いますので、 "env | sort"をスクリプトに入れてから、 "cap"コマンドを実行して環境情報を出力してください。私は今、同じ問題に取り組んでいます。私が何かを思いついたら教えてあげましょう。 – Harmon

+1

あなたのCapistranoスクリプトはどのユーザーが接続していますか?接続する相手を指定しないと、別のユーザーとして "git clone"を実行している可能性があります。デプロイメントホストからCapスクリプトを実行するユーザーは、デフォルトで使用されます。例えば、これは私たちのセットアップです: 'server"#{deploy_user} @#{hostname} "、:app、:db、:primary => true"と 'set:deploy_user、ENV ['USER']'。 – Harmon

答えて

5

を追加したところ、ローカルに保存された別のものでcap deployを実行する前に、元のdeploy.rbを置き換えることによってそれを解決しました。 jenkinsのログインシェルにはすでにsshエージェントが自動的に実行されている可能性がありますが、jenkinsがデプロイメントのために生成するコンテキストには対応していません。

は、あなたのジェンキンススクリプト内で手動で1を起動してみてください:これはあなたのために働く

# 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 

願っています!シェルは迷惑です。

+0

これはそれを修正しました。ありがとうございました! –

0

は、残念ながら、私は、私は我々がこれに似たものに走ったset :password, "sshpassword"

関連する問題