Open dtothefp opened 7 years ago
So it looks like from minimal investigation into the code that volumes are split on a newline rather than a space as it suggests in the docs https://github.com/jenkinsci/docker-plugin/blob/master/docker-plugin/src/main/java/com/nirima/jenkins/plugins/docker/DockerTemplateBase.java#L144
Using docker inspect
I found the string was not being split properly
//master
"HostConfig": {
"Binds": [
"/var/run/docker.sock:/var/run/docker.sock:rw",
"/usr/bin/docker:/usr/bin/docker:rw"
],
//slave
"HostConfig": {
"Binds": [
"/var/run/docker.sock:/var/run/docker.sock /usr/bin/docker:rw"
],
Adding a newline in the Jenkins UI input allows for command like which docker
to work in a build but when I run sudo docker run hello-world
I'm getting a strange error
+ docker run hello-world
docker: error while loading shared libraries: libltdl.so.7: cannot open shared object file: No such file or directory
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Thanks for investigating this
Would probably be better for plugin to rely on new Mounts
API to define bindings, and at least to offer a cleaner UI to define them.
About issue running docker
command it sounds like your docker image is missing minimal system libraries required by go runtime
Are there no updates about this? Slave isn't created when I enter volumes correctly on my side.
@pjdarton
https://github.com/jenkinsci/docker-plugin/blob/master/src/main/java/com/nirima/jenkins/plugins/docker/DockerTemplateBase.java#L395
should be splitAndFilterEmpty(mountsString, " ")
instead of "\n"
?
I don't think it's that simple - sometimes file paths have spaces in them 😢
Spaces in paths are a perpetual pain the backside and I wish there was a law against it but, unfortunately, at least one large multinational company decided that names like "Documents and Settings" or "Program Files (x86)" was a good idea, so a lot of folks tend to assume that it's OK to have spaces (and other weird characters) in file paths, so we can't really make the assumption that they never will have spaces.
I'm not opposed to the idea of splitting on spaces (or maybe "whitespace" in general) but if we were to choose to do that, we would also need to introduce a means of having spaces in pathnames (that doesn't rely on the space character itself).
e.g. we could use gitattributes [::space::]
notation, or
, %20
etc ... but all of these ideas would mean that the code would have to encode and decode the strings, and deal with auto-encoding existing configuration data if folks upgrade the plugin etc.
...which is why splitting on a linefeed character seemed to be an acceptable option - folks don't tend to put those into filenames with the expectation that everything will cope.
PS. "it was like that before I got here". The use of "\n" goes back to (well) before I got involved with this plugin and it didn't annoy me enough for me to change it ... but if it annoys you then feel free to do a PR ... as long as the PR still copes with spaces in filepaths 😉
Potentially similar to https://github.com/jenkinsci/docker-plugin/issues/206 but wanted to isolate this issue and see if I'm missing something with how the "Volumes" options works under the "Container Settings" menu.
I'm running a Jenkins Master using the official Jenkins Docker image. I'm bind mounting the docker socket into the Jenkins docker container as suggested here https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/:
This works fine for using
docker
commands within builds running on master.Now, I've switched to running jobs on a slave server using the Jenkins docker-plugin using the
evarga-jenkins-slave
image.A simple freestyle build works fine on the slave, but bind mounting the docker socket into the slave container using the "Volumes" option under "Container Settings" does not seem to work if I do
which docker
in the build it fails. Maybe there is something I don't understand about mounting volumes in the docker slave or am passing config incorrectly?Jenkins Version
Docker Version
Plugins
config.xml