Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Duplicate
-
None
-
CloudBees Docker Workflow 1.2
Jenkins ver. 1.625.3.1 (CloudBees Jenkins Enterprise 15.11)
Description
sshagent('my-ssh-key'){...} is ignored in docker.image('cloudbees:java-build-tools').inside{...}. The same sshagent step works in 'standard' linux node.
See attached logs
sshagent(){...} ignored in docker.image(...).inside{...}
docker.image ('cloudbees/java-build-tools:0.0.7.1').inside { sh 'ls -al ~/.ssh/ || true' sshagent(['aws-cleclerc-ssh-key-ubuntu-cleclerc']) { sh 'echo SSH_AUTH_SOCK=$SSH_AUTH_SOCK' sh 'ls -al $SSH_AUTH_SOCK || true' sh "ssh -vvv -o StrictHostKeyChecking=no ubuntu@docker-agent.beesshop.org uname -a" } }
sshagent(){...} WORKS in node{...}
node { sh 'ls -al ~/.ssh/ || true' sshagent(['aws-cleclerc-ssh-key-ubuntu-cleclerc']) { sh 'echo SSH_AUTH_SOCK=$SSH_AUTH_SOCK' sh 'ls -al $SSH_AUTH_SOCK || true' sh "ssh -vvv -o StrictHostKeyChecking=no ubuntu@docker-agent.beesshop.org uname -a" } }
Attachments
Issue Links
- duplicates
-
JENKINS-27152 Store sh control files outside of workspace
-
- Resolved
-
- is related to
-
JENKINS-42582 ssh-agent not applied in kubernetes container
-
- Resolved
-
Sure, we don't have to call it a "standard location" for agents, but given that the Jenkins package on, say, Ubuntu, installs to /var/lib/jenkins, maintaining a similar location on the agents would seem to be a sensible way to keep systems consistent, and far more obvious than setting it to /j.
Perhaps while this is being iterated upon there could be a feature toggle that could allow folks to fallback to the previous behavior if they need to?