customWorkspace should map workspace to a path inside of the container

[enaess]

Jenkins and plugins versions report

Environment

```text Jenkins: 2.516.3 OS: Linux - 6.8.0-83-generic Java: 21.0.8 - Amazon.com Inc. (OpenJDK 64-Bit Server VM) --- active-directory:2.40 analysis-model-api:13.9.0-911.v94cd6dcdedf7 ant:518.v8d8dc7945eca_ antisamy-markup-formatter:173.v680e3a_b_69ff3 apache-httpcomponents-client-4-api:4.5.14-269.vfa_2321039a_83 apache-httpcomponents-client-5-api:5.5-170.v023de017ccd7 asm-api:9.8-163.vb_2a_96d3f9c3c authentication-tokens:1.144.v5ff4a_5ec5c33 authorize-project:2.0.0 azure-credentials:395.vb_a_9203343ef5 azure-sdk:248.v0c922122245c bootstrap5-api:5.3.8-895.v4d0d8e47fea_d bouncycastle-api:2.30.1.82-277.v70ca_0b_877184 branch-api:2.1255.v2f5fe203584a_ build-timeout:1.38 caffeine-api:3.2.2-178.v353b_8428ed56 checks-api:373.vfe7645102093 cloud-stats:377.vd8a_6c953e98e cloudbees-folder:6.1053.vd62fb_b_f7367b_ command-launcher:123.v37cfdc92ef67 commons-compress-api:1.28.0-1 commons-lang3-api:3.19.0-104.v12125f33a_255 commons-text-api:1.14.0-194.v804a_dc3a_1b_d8 credentials:1447.v4cb_b_539b_5321 credentials-binding:702.vfe613e537e88 dark-theme:574.va_19f05d54df5 data-tables-api:2.3.4-1413.va_57c35d0a_9ec display-url-api:2.217.va_6b_de84cc74b_ docker-commons:457.v0f62a_94f11a_3 docker-java-api:3.5.3-122.v156e51f30c0a_ docker-plugin:1274.vc0203fdf2e74 docker-workflow:621.va_73f881d9232 dtkit-api:3.0.3 durable-task:605.v9a_b_9040c9970 echarts-api:6.0.0-1165.vd1283a_3e37d4 eddsa-api:0.3.0.1-19.vc432d923e5ee email-ext:1925.v1598902b_58dd emailext-template:233.v1eb_88fc160b_5 folder-properties:62.v1636b_4a_84608 font-awesome-api:7.0.1-872.vb_679b_2c95492 forensics-api:3.1772.v99ca_3d83b_9fa_ git:5.7.0 git-client:6.4.0 github:1.45.0 github-api:1.330-492.v3941a_032db_2a_ github-branch-source:1871.v50ffb_786515e gradle:2.16.1149.v711b_998b_0532 gson-api:2.13.2-173.va_a_092315913c http_request:1.20 instance-identity:203.v15e81a_1b_7a_38 ionicons-api:94.vcc3065403257 jackson2-api:2.20.0-411.v6ef8fdee4fe9 jakarta-activation-api:2.1.3-2 jakarta-mail-api:2.1.3-3 javax-activation-api:1.2.0-8 javax-mail-api:1.6.2-11 jaxb:2.3.9-133.vb_ec76a_73f706 jdk-tool:83.v417146707a_3d jfrog:1.5.10 jjwt-api:0.11.5-120.v0268cf544b_89 joda-time-api:2.14.0-149.v1c3ce991d1b_9 jquery3-api:3.7.1-619.vdb_10e002501a_ json-api:20250517-173.v596efb_962a_31 json-path-api:2.9.0-190.veefca_05d5477 jsoup:1.21.2-66.v6ea_38164b_8a_2 junit:1359.v71188fea_0df5 ldap:793.v754d6b_41b_ea_4 mailer:522.va_995fa_cfb_8b_d matrix-auth:3.2.8 matrix-project:858.vb_b_eb_9a_7ea_99e metrics:4.2.37-487.v7d6048d8733c mina-sshd-api-common:2.16.0-167.va_269f38cc024 mina-sshd-api-core:2.16.0-167.va_269f38cc024 netty-api:4.1.118.Final-9.v776038d601a_7 okhttp-api:4.12.0-195.vc02552c04ffd p4:1.17.2 pam-auth:1.12 pipeline-build-step:571.v08a_fffd4b_0ce pipeline-github-lib:65.v203688e7727e pipeline-graph-analysis:245.v88f03631a_b_21 pipeline-graph-view:646.va_da_a_047edca_c pipeline-groovy-lib:766.v2b_e08c2e6ff2 pipeline-input-step:534.v352f0a_e98918 pipeline-milestone-step:138.v78ca_76831a_43 pipeline-model-api:2.2273.v643f36ed9e94 pipeline-model-definition:2.2273.v643f36ed9e94 pipeline-model-extensions:2.2273.v643f36ed9e94 pipeline-stage-step:322.vecffa_99f371c pipeline-stage-tags-metadata:2.2273.v643f36ed9e94 pipeline-utility-steps:2.20.0 plain-credentials:199.v9f8e1f741799 plugin-util-api:6.1192.v30fe6e2837ff prism-api:1.30.0-630.va_e19d17f83b_0 resource-disposer:0.25 role-strategy:799.v5b_e7b_ecc231e scm-api:710.v7b_a_484d81f45 script-security:1378.vf25626395f49 slack:795.v4b_9705b_e6d47 snakeyaml-api:2.3-125.v4d77857a_b_402 ssh-agent:386.v36cc0c7582f0 ssh-credentials:361.vb_f6760818e8c ssh-slaves:3.1071.v0d059c7b_c555 sshd:3.374.v19b_d59ce6610 structs:353.v261ea_40a_80fb_ theme-manager:319.v9193461f9671 timestamper:1.30 token-macro:477.vd4f0dc3cb_cf1 trilead-api:2.209.v0e69b_c43c245 variant:70.va_d9f17f859e0 warnings-ng:12.9824.v4de304561b_de workflow-aggregator:608.v67378e9d3db_1 workflow-api:1384.vdc05a_48f535f workflow-basic-steps:1098.v808b_fd7f8cf4 workflow-cps:4209.v83c4e257f1e9 workflow-durable-task-step:1464.v2d3f5c68f84c workflow-job:1549.vc8d7f497b_22f workflow-multibranch:821.vc3b_4ea_780798 workflow-scm-step:452.vdf1ca_c8d3a_87 workflow-step-api:710.v3e456cc85233 workflow-support:991.v66c18437d509 ws-cleanup:0.49 ws-ws-replacement:1.0.1 xunit:3.1.5 ```

The software I am trying to build on Jenkins are sensitive to long paths. I can do the following in the scripted pipeline:

### What Operating System are you using (both controller, and any agents involved in the problem)?

I am running Jenkins controller on a Linux Ubuntu 24.04 box
I am running Jenkins agent(s) on Windows Server 2022.

The job is fanned out to a Windows server which does the build

### Reproduction steps

1. Create a pipeline that uses docker in one of it's stages

pipeline { agent { label "windows" } stages { stage("Build") { agent { docker { image 'my-builder-image:windows' label 'windows' args '''--mount type=bind,src=${JENKINS_REMOTE}\tools,dst=${JENKINS_REMOTE}\tools customWorkspace "C:\WS" } } steps { script { powershell label: "Build", script: ''' # Do build commands here ''' } } } // ... }

When you run this, the executor and workspace assigned to this build depends on Jenkins. Let's say it's something like: Organization\Group\Product\Jobs\MyJobHere. Say this path is pretty long, and pushes the max limit for paths on Windows at 255+ characters. Jenkins and other software handles this gracefully, just that I am coupling together something that is 20+ years old.

The above when you run it would start the docker container mapping the customWorkspace from the Host directly into the container. Say, that is C:\\WS then that's what you'll end up when you launch the container

docker run -d -t --mount type=bind,src=${JENKINS_REMOTE}\tools,dst=${JENKINS_REMOTE}\tools -w C:\\WS -v C:/WS:C:/WS -v C:/WS@tmp/:C:/WS@tmp/ -e ******** -e ******** -e ******** my-builder-image:windows  cmd.exe

Expected Results

What would be nice is if customWorkspace would map the current hosts' workspace to a path in the container with the right variables (if any, like e.g. WORKSPACE). That way I can check-out my sources on the windows host prior to the "Build" stage in job's WORKSPACE directory, but when executing inside of the container the customWorkspace mapped directly to the host's workspace is empty.

Actual Results

The C:/WS is mapped to the container's C:/WS, and I can't access the actual jobs ${WORKSPACE} where all sources are located.

Anything else?

I understand changing existing behavior can be difficult (or maybe this is indeed the desired behavior, I don't know).

Are you interested in contributing a fix?

No response