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

docker.stop() pipeline step no longer works for windows

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • docker-workflow-plugin
    • None
    • Jenkins 2.176.3
      org.jenkins-ci.plugins:docker-workflow:1.21
      org.jenkins-ci.plugins:docker-commons:1.15

      We believe the latest update to the docker-workflow-plugin may have broken the windows execution of the docker.stop() command within the pipeline (as it stopped working around that time)

      the pipeline is defined with the following steps:

      def compileContainer = docker.image("${env.COMPILE_IMAGE_TAG}").run("--name ${compileContainerName} -v ${escapedWorkspace}:C:/work", "ping -t localhost")
      
      ...
      
      compileContainer.stop()
      

      previously the job executed the above as follows:

      [2019-10-28T15:25:36.053Z] + docker run -d --name zen-32525-implement-ci_compiler_1572276306909 -v C:/Jenkins/workspace/_branches_ZEN-32525-Implement-CI:C:/work -v C:/ProgramData/buildportal/ssl:C:/ProgramData/buildportal/ssl zen-32525-implement-ci_compiler ping -t localhost
      
      ...
      
      [2019-10-28T15:41:01.985Z] + docker stop 675ac7e49c7528e046b9726cba057bb927abc7cafe658802f91a375972695230
      [2019-10-28T15:41:03.376Z] 675ac7e49c7528e046b9726cba057bb927abc7cafe658802f91a375972695230
      [2019-10-28T15:41:03.376Z] + docker rm -f 675ac7e49c7528e046b9726cba057bb927abc7cafe658802f91a375972695230
      [2019-10-28T15:41:03.637Z] 675ac7e49c7528e046b9726cba057bb927abc7cafe658802f91a375972695230
      

      however now the job fails at the stop step (and while the docker run does execute, it does not appear in the logs anymore)

      //blueocean shows - accompanied by no log output (but a container does appear on the host)
      Checks if running on a Unix-like node <1s
      Windows Batch Script 3s
      
      ...
      
      [2019-11-01T09:45:13.674Z] 
      
      [2019-11-01T09:45:13.674Z] administrator@WIN-1966SFQ4FES C:\Jenkins\workspace\_branches_ZEN-32525-Implement-CI>docker stop administrator@WIN-1966SFQ4FES C:\Jenkins\workspace\_branches_ZEN-32525-Implement-CI run -d --name zen-32525-implement-ci_compiler_1572600576646 -v C:/Jenkins/workspace/_branches_ZEN-32525-Implement-CI:C:/work -v C:/ProgramData/buildportal/ssl:C:/ProgramData/buildportal/ssl zen-32525-implement-ci_compiler ping -t localhost  1>docker 
      
      [2019-11-01T09:45:13.942Z] unknown shorthand flag: 'd' in -d
      
      [2019-11-01T09:45:13.942Z] See 'docker stop --help'.
      
      [2019-11-01T09:45:13.942Z] 
      
      [2019-11-01T09:45:13.942Z] administrator@WIN-1966SFQ4FES C:\Jenkins\workspace\_branches_ZEN-32525-Implement-CI>46e5dae3b97f6e443203a7e3a9c176257362c1a32b9e1ed23a11846ff878a7e0   && docker rm -f administrator@WIN-1966SFQ4FES C:\Jenkins\workspace\_branches_ZEN-32525-Implement-CI run -d --name zen-32525-implement-ci_compiler_1572600576646 -v C:/Jenkins/workspace/_branches_ZEN-32525-Implement-CI:C:/work -v C:/ProgramData/buildportal/ssl:C:/ProgramData/buildportal/ssl zen-32525-implement-ci_compiler ping -t localhost  1>docker 
      
      [2019-11-01T09:45:13.942Z] '46e5dae3b97f6e443203a7e3a9c176257362c1a32b9e1ed23a11846ff878a7e0' is not recognized as an internal or external command,
      
      [2019-11-01T09:45:13.943Z] operable program or batch file.
      
      [2019-11-01T09:45:13.943Z] 
      
      [2019-11-01T09:45:13.943Z] administrator@WIN-1966SFQ4FES C:\Jenkins\workspace\_branches_ZEN-32525-Implement-CI>46e5dae3b97f6e443203a7e3a9c176257362c1a32b9e1ed23a11846ff878a7e0
      
      [2019-11-01T09:45:13.943Z] '46e5dae3b97f6e443203a7e3a9c176257362c1a32b9e1ed23a11846ff878a7e0' is not recognized as an internal or external command,
      
      [2019-11-01T09:45:13.943Z] operable program or batch file.
      
      script returned exit code 1
      

      so it has now completely messed up the stop step - appearing to use the entire run command as the container id?

          [JENKINS-60016] docker.stop() pipeline step no longer works for windows

          I have confirmed that the container id has become the entire run command, by manually executing the bat command

          docker stop ${container.id}
          

          Dylan Yatigammana added a comment - I have confirmed that the container id has become the entire run command, by manually executing the bat command docker stop ${container.id}

          for anyone else with this issue, my workaround is to make sure I give the container a name, then manually run bat script to stop the container by name.

          e.g (something along these lines)

          String containerName = "containerName"
          
          //start container with containerName
          def compileContainer = docker.image("dockerImageName").run("--name ${containerName}", "ping -t localhost")
          
          //stop & rm container with containerName
          bat(script: "docker stop ${containerName}")
          bat(script: "docker rm -f ${containerName}")
          

          Dylan Yatigammana added a comment - for anyone else with this issue, my workaround is to make sure I give the container a name, then manually run bat script to stop the container by name. e.g (something along these lines) String containerName = "containerName" //start container with containerName def compileContainer = docker.image( "dockerImageName" ).run( "--name ${containerName}" , "ping -t localhost" ) //stop & rm container with containerName bat(script: "docker stop ${containerName}" ) bat(script: "docker rm -f ${containerName}" )

          Adam Talbot added a comment - - edited

          We are using the container.port method and we are seeing a similar error.

          A part of our code runs:
          String hostPort = container.port(containerPort.toInteger()).split(":")[1]

          And then fails:

          16:58:29 unknown shorthand flag: 'd' in -d
          16:58:29 See 'docker port --help'.

          To test this out, we tried running simply:
          String containerId = container.id
          println("id: ${containerId}")

          And we got this output:

          16:58:28 [Pipeline] echo
          16:58:28 id: C:\jenkins\workspace[redacted branch name]>docker run -d --storage-opt size=100G --isolation=hyperv -e MSSQL_MEMORY_LIMIT_MB="4096" --memory=8g -p 1433 [redacted image location]:33
          16:58:28 3168f8a6d2e45d4ff749d06e9ccff805ef4fc410c1edb53cea905bd571a61f92

          Given this, we are suspecting that the solution to this bug would involve adding @echo off to the underlying batch scripts.

          Adam Talbot added a comment - - edited We are using the container.port method and we are seeing a similar error. A part of our code runs: String hostPort = container.port(containerPort.toInteger()).split(":") [1] And then fails: 16:58:29 unknown shorthand flag: 'd' in -d 16:58:29 See 'docker port --help'. To test this out, we tried running simply: String containerId = container.id println("id: ${containerId}") And we got this output: 16:58:28 [Pipeline] echo 16:58:28 id: C:\jenkins\workspace [redacted branch name] >docker run -d --storage-opt size=100G --isolation=hyperv -e MSSQL_MEMORY_LIMIT_MB="4096" --memory=8g -p 1433 [redacted image location] :33 16:58:28 3168f8a6d2e45d4ff749d06e9ccff805ef4fc410c1edb53cea905bd571a61f92 Given this, we are suspecting that the solution to this bug would involve adding @echo off to the underlying batch scripts.

          Bram added a comment - - edited

          Facing the same issues and I hope someone is out there watching over the Windows implementation. Not meant in a negative way, but I worry a little bit in terms of expectation.

          Currently we try to get things working with calling docker from docker containers on a kubernetes platform with Windows nodes (AKS). This is only one of the issues out there regarding this plugin, we also face a work folder mount issue as part of the inside() call that is described in a different issue ( https://issues.jenkins.io/browse/JENKINS-61498 ). I link to that issue here because both these issues are quite of age and block proper use of build containers within pipeline scripts on Windows using the docker pipeline/workflow DSL.

          (docker ee windows client version in use: 20.10.0 installed as extension on the jenkins/inboundagent:windowsservercore-1809 image; docker client build has been downloaded from https://dockermsft.azureedge.net/dockercontainer/docker-20-10-0.zip; installed plugin version: 1.26; jenkins version: 2.277.1)

           

          Bram added a comment - - edited Facing the same issues and I hope someone is out there watching over the Windows implementation. Not meant in a negative way, but I worry a little bit in terms of expectation. Currently we try to get things working with calling docker from docker containers on a kubernetes platform with Windows nodes (AKS). This is only one of the issues out there regarding this plugin, we also face a work folder mount issue as part of the inside() call that is described in a different issue ( https://issues.jenkins.io/browse/JENKINS-61498  ). I link to that issue here because both these issues are quite of age and block proper use of build containers within pipeline scripts on Windows using the docker pipeline/workflow DSL. (docker ee windows client version in use: 20.10.0 installed as extension on the jenkins/inboundagent:windowsservercore-1809 image; docker client build has been downloaded from https://dockermsft.azureedge.net/dockercontainer/docker-20-10-0.zip ; installed plugin version: 1.26; jenkins version: 2.277.1)  

            Unassigned Unassigned
            dnbyatigammana Dylan Yatigammana
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: