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

git isn't run inside build container

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            dcserrot 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!

            dcserrot 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!
            markewaite 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

            markewaite 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
            sdarwin 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.

             

            sdarwin 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.  
            duemir 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).

            duemir 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).
            ysmaoui 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...

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

            People

              Unassigned Unassigned
              ndeloof Nicolas De Loof
              Votes:
              22 Vote for this issue
              Watchers:
              35 Start watching this issue

              Dates

                Created:
                Updated: