[JENKINS-74912] Fix Docker Windows non-C workspaces

[MarkRx]

Docker windows running windows does not support mounting non-C drive paths. It does however support mounting the entire drive. This change mounts the entire drive when we detect a non-C drive is being used for the workspace as a workaround.

Change includes a test that runs on Windows when Windows containers are enabled and a D drive exists (or gets skipped otherwise). Additionally tests now ensure docker is running in the corresponding OS mode using Assume.

Merge #326 first.

See JENKINS-74912
See Stack Overflow
See Github #41681

Testing done

• Unit test exists to test case if underlying os and installed software support it (Windows, windows containers, D drive mounted)
• Tested on a running instance with the following:

pipeline {
    agent {
        label 'docker_windows1809'
    }

    stages {
        stage('Stage') {
            steps {
                ws("N:/jenkins/multi space space") {
                    script {
                        docker.image('microsoft-images-docker.registry.paychex.com/windows/servercore:ltsc2019').inside {
                            bat "echo %cd%"
                        }
                    }
                }
            }
        }
    }
}

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 demonstrates feature works or fixes the issue

[basil]

Seems like silently mounting the whole drive would violate the principle of least surprise.

[MarkRx]

Seems like silently mounting the whole drive would violate the principle of least surprise.

The alternative would be to put the logic in WithContainerStep since that directly controls what is mounted. I'm making that change now.

[basil]

Same feedback applies. Seems surprising to mount the whole drive when the user requested only a subdirectory to be mounted. What if the drive contained a secret that the user did not want to expose?

[MarkRx]

I updated the title to avoid confusion. The latest change only works around if the workspace is on a different drive.

Users wouldn't interface with this logic. The plugin controls when the workspace is bind mounted to the container when launching it. Any manual user arguments (such as volumes) would still be passed in verbatim. I updated the title to reflect this - instead of changing all volumes the workaround only applies if the Jenkins workspace is on a different drive. Users can control the value the pass with -v so can (and will have to) workaround any non-C mounts themselves by mounting the whole drive explicitly.

Permissions would be no different than a job that ran directly on the agent as the entire drive would already be mounted and available. If D:/foo is accessible from the agent, then D:/foo will be accessible by the container. If D:/foo is not accessible by the agent then D:/foo will not be accessible by the container provided the container runs as the same user. In other words mounting a separate volume in the container would look the same as not running inside the container.

[basil]

Sorry, I can't understand the above explanation. That might be because I don't know much about Windows Docker or this plugin. Might be best to wait for another reviewer or to adopt the plugin instead.