Thanks for the explanation. It helps me understand why that path does not
exist. I added 'jenkins' to the root group, and then chmod'd 775 on /.
Unfortunately, this doesn't work either. When I do this, I suspect the
workspace is being mounted at /, which breaks all the things (specifically,
the SSH injection path is broken causing the provisioning to fail).
Is it really essential to use a non-standard directory here?
> No, not necessarily, however solving this would enable support for any
legal path in that field. And, it does seem to be a legal value according
to declarative pipeline, as following code works.
pipeline {
agent none
stages {
stage('Foo') {
agent {
node {
label 'dind'
customWorkspace '/test'
}
}
steps {
sh 'ls -l /test'
*Things only break when I expose the host to my ephemeral agents. *If I
rely on the docker daemon within the ephemeral agent to pull and run
pipeline, everything works. Unfortunately, this means pulling every image
in every stage every time.
The former is a peer-relationship between the build agent and the dind
host. The latter is a parent child relationship. At the time "docker run -w
/foo/bar -v /foo/bar:/foo/bar is called, if /foo/bar does not exist on
either host or container, they are created. It makes sense why this works
in the parent-child relationship. I expected that when I tried to run the
same command as the jenkins user, against the dind-docker host emulating
the "expose DOCKER_HOST" functionality, that the -v /foo/bar:/foo/bar
mapping would fail. But it didn't. It created that path in the container
and dind-docker.
So I am perplexed now. I haven't been able to recreate it outside of
Jenkins, but I think it must have something to do with the "docker run"
command and file permissions.
Any advice on either 1. some other caching mechanism beside "expose
DOCKER_HOST", or 2. point me at the relevant section of code for the
docker-plugin, or 3. I'm way off base and need more help :)? Similar to
mounting a volume to /home/jenkins, could the plugin mount a volume to back
absolute paths?
Any thoughts?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/64e43925-40a0-4951-a947-271a93f0fb90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
