Type: New Feature
Status: Open (View Workflow)
Linux-Machine (2-Cores - Master, others for Linux-Slave):
Linux 3.10.0-1062.12.1.e17.x86_x64 GNU/Linux
OS Name: Microsoft Windows Server 2016 Datacenter
OS Version: 10.0.14393 N/A Build 14393
I want to have a possibility to change the "workdir" & "volume" destination directory within the image which will be started by the "docker.image.inside"-command.
The current problem is that the path to the mount-destination within the container and the working directory are hard-coded:
Hard-coded Work-Dir (parameter 4 is always "ws" == "workspace"):
So the "default" image.inside command (on windows) results in something like:
It's not "clean" because the destination in the started container is hardcoded as the same directory of the workspace. This can cause issues with rights, existing drives, and other stuff.
Feature-Request in short:
I want to have the possibility to change the working directory and the volume mounting directory which points into the started container.
- The default behavior can be kept as it is
I have two proposals (from the user side of view) attached in (proposal.txt)
It would be nice to make the "image.inside" command will result in something like this:
Background how I ran into this:
My System is a Jenkins-Master on a Linux-Server. I have two Slaves one Linux & one Windows.
- all this are real physical machines, no VM's or other stuff
- The Windows-Slave has a Windows-Server 2016 OS
In my case the "workspace" of Jenkins is on the "E"-Drive.
If you run the attached "example.txt" you can reproduce the error on every jenkins
- of course on my machine, dont need the "ws(...)" part
The Error is an error on the docker run command because docker is unable to create a new Drive, as mounting point in the created container.
- I tried very much to create a "E"-Drive as volume in the Image, but I wasn't able to make it
- I tried symlinks, registry changes and stuff ...
- after all this I looked into the Code of the Plugin and thought this should be changeable ...
All in all I think the origin of the problem are the hard-coded directories within the containers.