Using docker-slaves, the checkout build phase is ran with commands inside the remoting container (which by change has git) not inside the configured build container.

      This is due to git-client to create it's own LocalLauncher vs using the Node's one.

          [JENKINS-30600] git isn't run inside build container

          This also affects K8N plugin when you use pod+container: 

          podTemplate(cloud: 'kubernetes', containers: [containerTemplate(args: '-c', command: '/bin/bash ', image: 'image with git ca-cert', name: 'base', workingDir: '/home/jenkins')], label: 'base') {
            node('base'){
              container('base')

          {       git credentialsId: 'something', url: '[https://some-ca-cert-git|https://some/].git' }

          }

          Tomas Hartmann added a comment - This also affects K8N plugin when you use pod+container:  podTemplate(cloud: 'kubernetes', containers: [containerTemplate(args: '-c', command: '/bin/bash ', image: 'image with git ca-cert', name: 'base', workingDir: '/home/jenkins')] , label: 'base') {   node('base'){     container('base') {       git credentialsId: 'something', url: '[https://some-ca-cert-git|https://some/].git' } }

          Ian Panzer added a comment -

          Any update on this issue? Encountering it in a k8s environment on AWS.

          Ian Panzer added a comment - Any update on this issue? Encountering it in a k8s environment on AWS.

          Mark Waite added a comment -

          No change faroguy0

          Mark Waite added a comment - No change faroguy0

          Are there any plans to actually fix this?

          Piotr Niebylski added a comment - Are there any plans to actually fix this?

          Mark Waite added a comment -

          There have been 3 attempts to fix it. All 3 attempts failed because they were unable to retain compatibility with existing installations and existing code. Additional attempts are certainly welcomed.

          I don't plan to attempt a fix in the next 12 months.

          Mark Waite added a comment - There have been 3 attempts to fix it. All 3 attempts failed because they were unable to retain compatibility with existing installations and existing code. Additional attempts are certainly welcomed. I don't plan to attempt a fix in the next 12 months.

          Dani T added a comment - - edited

          Does anyone know any workaround? In my case I want to take advantage of the credentials used in the host to perform a git push.

          Regards!

          Dani T added a comment - - edited Does anyone know any workaround? In my case I want to take advantage of the credentials used in the host to perform a git push. Regards!

          Mark Waite added a comment -

          Use a Pipeline, wrap your own custom call to `git clone` or `git fetch` with a `withCredentials` wrapper as described in the git plugin documentation of the `withCredentials block

          Mark Waite added a comment - Use a Pipeline, wrap your own custom call to `git clone` or `git fetch` with a `withCredentials` wrapper as described in the git plugin documentation of the `withCredentials block

          Sam Darwin added a comment -

          Hi, I just saw an error in a jenkins job:

          "07:50:43 Warning: JENKINS-30600: special launcher com.cloudbees.jenkins.plugins.docker_build_env.DockerDecoratedLauncher@5ed555df; decorates RemoteLauncher[hudson.remoting.Channel@1c49281:EC2 (__) - jenkinspool1 (i-0b2aadb0c68d3dc94)] will be ignored (a typical symptom is the Git executable not being run inside a designated container)

          Could someone explain what this means, in simple terms?    What bug is happening to the job?    The explanation in the above description isn't clear.

           

          Sam Darwin added a comment - Hi, I just saw an error in a jenkins job: "07:50:43 Warning: JENKINS-30600 : special launcher com.cloudbees.jenkins.plugins.docker_build_env.DockerDecoratedLauncher@5ed555df; decorates RemoteLauncher [hudson.remoting.Channel@1c49281:EC2 (__) - jenkinspool1 (i-0b2aadb0c68d3dc94)] will be ignored (a typical symptom is the Git executable not being run inside a designated container) Could someone explain what this means, in simple terms?    What bug is happening to the job?    The explanation in the above description isn't clear.  

          Denys Digtiar added a comment -

          sdarwin I cannot find which plugin that launcher decorator comes from, so I am unsure what it is doing. If it is just modifying the environment, there might be no issue.

          The problem is most acute when the container wrapper from the Kubernetes plugin or Docker plugins' inside container feature is used. Both use Launcher decorator to change where external processes are executed, but the Git plugin ignores it. For example, you think that by wrapping git step in the container wrapper, you would execute git CLI in the specified container. Still, it is not the case, git CLI is always executed in the same container where the Jenkins agent process is running (jnlp container in case of the Kubernetes plugin).

          Denys Digtiar added a comment - sdarwin I cannot find which plugin that launcher decorator comes from, so I am unsure what it is doing. If it is just modifying the environment, there might be no issue. The problem is most acute when the container wrapper from the Kubernetes plugin or Docker plugins' inside container feature is used. Both use Launcher decorator to change where external processes are executed, but the Git plugin ignores it. For example, you think that by wrapping git step in the container wrapper, you would execute git CLI in the specified container. Still, it is not the case, git CLI is always executed in the same container where the Jenkins agent process is running ( jnlp container in case of the Kubernetes plugin).

          Yacine added a comment - - edited

          is this also affecting sshagent? ( so not only checkout scm ) ?

          so the ssh keys in the following snippet are not setup correctly inside the container block in the following example

          podTemplate(...) {
              node("<myLabel>"){
                  container("<myContainer>"){
          
                      sshagent([credentialsId]){
                          sh("do something that requires the ssh auth")
                      }
                  }
              }  
          }
          

          UPDATE:

          No issue with the sshagent step: the ssh-agent command is indeed executed in the correct container

          but the knownhosts file was not updated:
          the checkout scm step, updates automatically the knownhosts file
          so if we run in the same container where the checkout scm was executed, sshagent works without problems.

          but if we switch containers and execute on a different container than 'jnlp' ( reminder of the main topic in this ticket: checkout scm is always executed in the container named 'jnlp' )
          then in the new container the knowshosts file needs to be updated manually...

          Yacine added a comment - - edited is this also affecting sshagent? ( so not only checkout scm ) ? so the ssh keys in the following snippet are not setup correctly inside the container block in the following example podTemplate(...) { node( "<myLabel>" ){ container( "<myContainer>" ){ sshagent([credentialsId]){ sh( " do something that requires the ssh auth" ) } } } } UPDATE: No issue with the sshagent step: the ssh-agent command is indeed executed in the correct container but the knownhosts file was not updated: the checkout scm step, updates automatically the knownhosts file so if we run in the same container where the checkout scm was executed, sshagent works without problems. but if we switch containers and execute on a different container than 'jnlp' ( reminder of the main topic in this ticket: checkout scm is always executed in the container named 'jnlp' ) then in the new container the knowshosts file needs to be updated manually...

            Unassigned Unassigned
            ndeloof Nicolas De Loof
            Votes:
            25 Vote for this issue
            Watchers:
            38 Start watching this issue

              Created:
              Updated: