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

withDockerRegistry fails to authenticate with DockerHub

      When using either docker.withRegistry('', 'dockerhub') or withDockerRegistry(registry: [credentialsId: 'dockerhub']), a call to mycont.push() fails to authenticate with DockerHub:

        withDockerRegistry(registry: [credentialsId: 'dockerhub']) {
          cont.push()
          cont.push('latest')
        }
      

      leads to:

      Proceeding
      [Pipeline] withDockerRegistry
      [Pipeline] {
      [Pipeline] sh
      [test] Running shell script
      + docker tag --force=true camptocamp/jenkins-test camptocamp/jenkins-test:latest
      unknown flag: --force
      See 'docker tag --help'.
      + docker tag camptocamp/jenkins-test camptocamp/jenkins-test:latest
      [Pipeline] sh
      [test] Running shell script
      + docker push camptocamp/jenkins-test:latest
      The push refers to a repository [docker.io/camptocamp/jenkins-test]
      749689370cd8: Preparing
      unauthorized: authentication required
      [Pipeline] }
      [Pipeline] // withDockerRegistry
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      

      I have the credentials set up properly in Jenkins, as shown in the attached screenshot, but Jenkins Credentials Manager says `This credential has not been recorded as used anywhere.`

          [JENKINS-38018] withDockerRegistry fails to authenticate with DockerHub

          Jesse Glick added a comment -

          AFAICT unrelated issues are being discussed here.

          First, as originally reported by saisse, if you were using the syntax withDockerRegistry([…]), this seems to have stopped working after the introduction of the toolName parameter, I think due to a core Pipeline bug (though I had thought this was fixed years ago). Will investigate. To fix, simply be explicit about the registry: parameter name. (The DSL sugar docker.withRegistry internally calls the working syntax of the step.)

          Second, vwbusguy, schulzha, and perhaps nicolasus are reporting unrelated issues ultimately due to a failure to run a docker login command. I cannot help you with that; something is broken in your environment. The new version of docker-workflow deliberately just calls the Docker CLI to log in, rather than attempting to fake the undocumented JSON authentication file format. Log in to your build node with a shell and run docker login with the same username and password until you track down the issue (for example, I saw a file permission issue on docker.sock).

          timothy_clarke mentioned in passing a failure to mask passwords from the docker login command, which I have not seen and would not know how to reproduce. Seems to be some bug in the Kubernetes plugin, perhaps. File separately with complete steps to reproduce from scratch.

          Jesse Glick added a comment - AFAICT unrelated issues are being discussed here. First, as originally reported by saisse , if you were using the syntax withDockerRegistry([…]) , this seems to have stopped working after the introduction of the toolName parameter, I think due to a core Pipeline bug (though I had thought this was fixed years ago). Will investigate. To fix, simply be explicit about the registry: parameter name. (The DSL sugar docker.withRegistry internally calls the working syntax of the step.) Second, vwbusguy , schulzha , and perhaps nicolasus are reporting unrelated issues ultimately due to a failure to run a docker login command. I cannot help you with that; something is broken in your environment. The new version of docker-workflow deliberately just calls the Docker CLI to log in, rather than attempting to fake the undocumented JSON authentication file format. Log in to your build node with a shell and run docker login with the same username and password until you track down the issue (for example, I saw a file permission issue on docker.sock ). timothy_clarke mentioned in passing a failure to mask passwords from the docker login command, which I have not seen and would not know how to reproduce. Seems to be some bug in the Kubernetes plugin, perhaps. File separately with complete steps to reproduce from scratch.

          Jesse Glick added a comment -

          Filed the syntax issue as JENKINS-51395.

          Jesse Glick added a comment - Filed the syntax issue as  JENKINS-51395 .

          I just want to confirm that 1.16 is not working. My team had to downgrade the plugin back to 1.15.1 to get things rolling.

          Jonatan Landsberg added a comment - I just want to confirm that 1.16 is not working. My team had to downgrade the plugin back to 1.15.1 to get things rolling.

          Nico Navarrete added a comment - - edited

          Just to comment, probably, as commented , there are multiple issues here, and first of all thank you all or the work and efforts done to make jenkins works with docker.

           

          In my case I don't think it's an environment (only) problem, it works perfectly with plugin version 1.15.1 and it doesn't work at all with plugin version 1.16.

           

          What I'm doing is a docker development cycle pipeline, that builds dockers inside a jenkins-ssh-slave (dockerized) running from a dockerized jenkins master (2.107.3).

           

          This pipeline builds the docker images in the slave, connecting to the remote dockerd, and push the image to the private docker registry (nexus).

           

          Well in this scenario, the `docker` command should take the DOCKER_HOST from the environment and authenticate to the docker private registry.

           

          With the update this stopped to work

           

              // run from base dir for folder builds and from tmp for url builds
              dir ("$runPwd") {
                  echo "Build with server ${env.DOCKER_HOST} and registry ${env.CP_DOCKER_RELEASE}"
                  docker.withServer(env.DOCKER_HOST) {
                      docker.withRegistry(env.CP_DOCKER_RELEASE,env.DOCKER_CREDENTIALS ){
                          echo "Execute docker build -t $name:$version $params"
                          sh "docker   build -t $name:$version $params"
          //                def image = docker.build ("$name:$version", params)
                      }
                  }
              }
          

          After I downgrade version to 1.15.1 this works again with no other change.

           

          If it's required a change in configuration or parameters I suppose it should be documented or have sensitive defaults to act as previous versions and continue to work as expected or be "adapted" with the new/changed configuration/parameters.

           

          I f you need any help on variable values or Dockerfile's or conatiner o whatever may help don't hesitate to ask, I'll give whatever may help.

           

          Thanks again,

          Nico

           

           

           

           

          Nico Navarrete added a comment - - edited Just to comment, probably, as commented , there are multiple issues here, and first of all thank you all or the work and efforts done to make jenkins works with docker.   In my case I don't think it's an environment (only) problem, it works perfectly with plugin version 1.15.1 and it doesn't work at all with plugin version 1.16.   What I'm doing is a docker development cycle pipeline, that builds dockers inside a jenkins-ssh-slave (dockerized) running from a dockerized jenkins master (2.107.3).   This pipeline builds the docker images in the slave, connecting to the remote dockerd, and push the image to the private docker registry (nexus).   Well in this scenario, the `docker` command should take the DOCKER_HOST from the environment and authenticate to the docker private registry.   With the update this stopped to work       // run from base dir for folder builds and from tmp for url builds     dir ( "$runPwd" ) {         echo "Build with server ${env.DOCKER_HOST} and registry ${env.CP_DOCKER_RELEASE}"         docker.withServer(env.DOCKER_HOST) {             docker.withRegistry(env.CP_DOCKER_RELEASE,env.DOCKER_CREDENTIALS ){                 echo "Execute docker build -t $name:$version $params"                 sh "docker   build -t $name:$version $params" //                def image = docker.build ( "$name:$version" , params)             }         }     } After I downgrade version to 1.15.1 this works again with no other change.   If it's required a change in configuration or parameters I suppose it should be documented or have sensitive defaults to act as previous versions and continue to work as expected or be "adapted" with the new/changed configuration/parameters.   I f you need any help on variable values or Dockerfile's or conatiner o whatever may help don't hesitate to ask, I'll give whatever may help.   Thanks again, Nico        

          Jesse Glick added a comment -

          nicolasus hmm, I suspect your issue is specific to the combination of withDockerServer and withDockerRegistry, something we have no tests for due to the technical difficulty of simulating these environments. I think I know what the issue is there and have filed it as JENKINS-51397.

          Jesse Glick added a comment - nicolasus hmm, I suspect your issue is specific to the combination of withDockerServer and withDockerRegistry , something we have no tests for due to the technical difficulty of simulating these environments. I think I know what the issue is there and have filed it as JENKINS-51397 .

          Alex Al added a comment -

          nicolasus, the same here. After downgrading to version 1.15.1 everything works fine. Jenkins 2.107.3.

          Alex Al added a comment - nicolasus , the same here. After downgrading to version 1.15.1 everything works fine. Jenkins 2.107.3.

          Jesse Glick added a comment -

          Please do not comment further on this issue. Check JENKINS-51395 and JENKINS-51397, or file a fresh bug and link it here if you are sure you have encountered a distinct issue.

          Jesse Glick added a comment - Please do not comment further on this issue. Check JENKINS-51395 and JENKINS-51397 , or file a fresh bug and link it here if you are sure you have encountered a distinct issue.

          Jesse Glick added a comment -

          Filed JENKINS-51406 & JENKINS-51407 for integration into other non-Pipeline plugins, so this issue can be considered strictly about Docker Pipeline.

          Jesse Glick added a comment - Filed JENKINS-51406 & JENKINS-51407 for integration into other non-Pipeline plugins, so this issue can be considered strictly about Docker Pipeline.

          jglick What docker login environment problem?  Docker login works fine from CLI, ansible, or this plugin from 1.15.1 and previous.  Between this and the breaking ENTRYPOINT in 1.15.x, I'm at my last straw with this plugin and possibly even Jenkins itself as Docker has become such a core of our operations.  I'm happy to help test and possibly contribute code, but I just can't continue having my teams rely on a feature that has major regressions every update and the CloudBees devs keep dismissing the people reporting the issues and trying to fix them.  It's never fun when we have to keep spending our time debugging and coding workarounds for this plugin rather than the code we're trying to test to begin with. 

          Scott Williams added a comment - jglick What docker login environment problem?  Docker login works fine from CLI, ansible, or this plugin from 1.15.1 and previous.  Between this and the breaking ENTRYPOINT in 1.15.x, I'm at my last straw with this plugin and possibly even Jenkins itself as Docker has become such a core of our operations.  I'm happy to help test and possibly contribute code, but I just can't continue having my teams rely on a feature that has major regressions every update and the CloudBees devs keep dismissing the people reporting the issues and trying to fix them.  It's never fun when we have to keep spending our time debugging and coding workarounds for this plugin rather than the code we're trying to test to begin with. 

          Jesse Glick added a comment -

          vwbusguy please see the linked issues and update your plugins.

          Jesse Glick added a comment - vwbusguy please see the linked issues and update your plugins.

            jglick Jesse Glick
            raphink Raphaël PINSON
            Votes:
            16 Vote for this issue
            Watchers:
            35 Start watching this issue

              Created:
              Updated:
              Resolved: