Fix WithContainerStep when hasWorkdir is false for Windows Containers

[mcayland-ntx]

The existing logic in the Decorator class sets hasWorkDir if the docker version is newer than 17.12. In the case where hasWorkDir is false, the fallback logic in the decorate() method updates the starter cmds() but always uses a UNIX-like "sh" command, which causes Jenkins to hang and timeout when using Windows Containers.

Update the logic in the decorate() method to provide an implementation for Windows Containers that prepends the appropriate "cd" command followed by && to the generated command.

Testing done

This change was tested using Jenkins to build Windows Containers using nerdctl/containerd as a Docker replacement using the docker-workflow-plugin. The codepath in question is not normally used, but is triggered because nerdctl reports a version of 2.1.6 which is earlier than 17.12.

Without this patch, Jenkins hangs when executing the bat container step due to the UNIX-style "sh" fallback implemented which blocks and eventually causes the build to timeout.

If the automated test coverage is using the official Docker installer then it is impossible to trigger this codepath because it always reports a version later than 17.12.

Related issues:
https://issues.jenkins.io/browse/JENKINS-75102
#326

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[felipegrazziotin]

I have independently verified Mark's patch. My setup was a Jenkins 2.528.1 with docker-workflow 634.vedc7242b_eda_7, trying to schedule containers on an agent running on Windows 2019 server.

The container engine I'm running on this Windows 2019 is also nerdctl as installed per these instructions: https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=containerd

NerdCTL is installed on C:\Program Files\nerdctl and this is added to the path.

I had to make a copy of nerdctl.exe and call it docker.exe as the code is coupled with expecting everything called docker.

My pipeline on Jenkins is as simple as:

pipeline {
    agent {
        docker {
            label 'node-windows'
            image 'mcr.microsoft.com/windows/nanoserver:ltsc2019'
            //customWorkspace 'c:\\jenkins\\workspace\\dockerised'
        }
    }

    stages {
        stage('run on container') {
            steps {
                bat "hostname & echo running"
            }
        }
    }
}

I was unable to get the bat execution on docker-workflow 634.vedc7242b_eda_7, the pipeline would just hang forever as if it was waiting to read something, despite the container being up and running.

Using the patch in this pull I was able to see that the code really executed on the container it created.