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

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

    XMLWordPrintable

Details

    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

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-27152 Store sh control files outside of workspace

          • Major - Major loss of function.
          • Resolved
          is related to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-42582 ssh-agent not applied in kubernetes container

          • Major - Major loss of function.
          • Resolved

          Activity

            Ascending order - Click to sort in descending order
            View 7 older comments
            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?

            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?
            jglick Jesse Glick added a comment -

            Which previous behavior are you referring to?

            jglick Jesse Glick added a comment - Which previous behavior are you referring to?
            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?

            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?
            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.

            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 .
            jglick Jesse Glick added a comment -

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

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: