Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-32624

sshagent{} ignored when executed in docker.image().inside{...}

    XMLWordPrintable

    Details

    • Similar Issues:

      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

            Activity

            Hide
            jglick Jesse Glick added a comment -

            The previous naming pattern for branch projects can be restored with a system property, see release notes.

            Show
            jglick Jesse Glick added a comment - The previous naming pattern for branch projects can be restored with a system property, see release notes.
            Hide
            jspiewak Joshua Spiewak added a comment -

            I am referring to the previous behavior that stored the workspace in sub-folders without the base32 of the hash that was introduced for JENKINS-34564.

            Show
            jspiewak Joshua Spiewak added a comment - I am referring to the previous behavior that stored the workspace in sub-folders without the base32 of the hash that was introduced for JENKINS-34564 .
            Hide
            erliz Stanislav Vetlovskiy added a comment - - edited

            I faced with the same issue, all was good on simple pipeline, but when i switched to multi-branch pipeline job, tasks in sshagent fall with error

            SSH_AUTH_SOCK=/tmp/ssh3569037635123687207
            + ls -al /tmp/ssh3569037635123687207
            ls: cannot access /tmp/ssh3569037635123687207: No such file or directory
            

            is there any advice to fix it or some workaround?

            Show
            erliz Stanislav Vetlovskiy added a comment - - edited I faced with the same issue, all was good on simple pipeline, but when i switched to multi-branch pipeline job, tasks in sshagent fall with error SSH_AUTH_SOCK=/tmp/ssh3569037635123687207 + ls -al /tmp/ssh3569037635123687207 ls: cannot access /tmp/ssh3569037635123687207: No such file or directory is there any advice to fix it or some workaround?
            Hide
            jglick Jesse Glick added a comment -

            Which previous behavior are you referring to?

            Show
            jglick Jesse Glick added a comment - Which previous behavior are you referring to?
            Hide
            jspiewak Joshua Spiewak added a comment -

            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?

            Show
            jspiewak Joshua Spiewak added a comment - 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?

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                cleclerc Cyrille Le Clerc
              • Votes:
                1 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: