Is it necessary to VOLUME the jenkins home dir? about docker-agent HOT 17 CLOSED

I assume it's for JAR cache, which is being stored in home dir now.
Should be fixed/broken by https://issues.jenkins-ci.org/browse/JENKINS-18578 in remoting 3

from docker-agent.

Thanks. Wouldn't it be enough then to mark /home/jenkins/.jenkins as a volume?

from docker-agent.

@carlossg WDYT?

from docker-agent.

@oleg-nenashev is the jenkins slave copying data only to ~/.jenkins ? then it makes sense to use that as a volume, or nothing at all

from docker-agent.

@carlossg Jenkins slave itself should not use other directories in home dir. I'm not sure about Jenkins core's logic and plugins hooking on it

from docker-agent.

Great! Thanks @carlossg

from docker-agent.

@staffan-einarsson any reason you don't use jenkins credentials support to manage ssh keys ? Should not need to customize slave's $HOME.

from docker-agent.

@staffan-einarsson I'd like to revert this. Not making HOME a volume means workspace isn't created on a volume, .m2, .npm and others won't get cached, etc.

from docker-agent.

I think you can still put it in a volume, it's just the user responsibility to do it

from docker-agent.

You indeed can run the image and force /home/jenkins to be a volume, but as a result will have two volumes, one for /home/jenkins and one for /home/jenkins/.jenkins, which doesn't make much sense imo, and also make it harder to persist agent environment. Other option is to just not declare a volume

from docker-agent.

I mean if we remove the volume definition and make it user's responsibility to deal with volumes

from docker-agent.

@carlossg yes indeed, image doesn't need to declare a volume, end-user can just run with -v slaveroot:/home/jenkins. Initial content from image will then be copied into this volume.
This would just require end-user to know this path should be a volume, so have to make it clear in documentation.

from docker-agent.

Sorry for late follow up. @ndeloof For my specific case it I was using a plugin that did integrate with Jenkins credentials and having user SSH keys was a valid work-around. More generally, a lot of environment config goes in the home dir so it is not unreasonable to want to be able to set it up when building the image.

Yes, I agree. It would be better to leave the decision of whether to make it a volume to the user. It sounds like persisting caches is the main argument, as an optimization. I could equally see the use case that you want to wipe the caches between starts to make sure you have a clean starting point.

from docker-agent.

@staffan-einarsson the main argument is not about persisting jar cache - this one could not be persisted. The main argument is about persisting slave root to persist workspaces and tool installations, so you can retrieve them on next build.

Environment configuration should not live in slave $HOME but rely on Jenkins mechanism to inject configuration.

from docker-agent.

@ndeloof, @carlossg Seems that latest version of image was not created based on jenkinsci/slave that had this change. I did run docker inspect for both latest from repo and results were following

jenkinsci/slave:latest
"Created": "2016-09-14T09:31:24.487360509Z"
"Volumes": { "/home/jenkins/.jenkins": {} }

jenkinsci/jnlp-slave:latest
"Created": "2016-09-14T09:02:01.065000398Z"
"Volumes": { "/home/jenkins": {} }

So if you use jnlp-slave as base image you will still have volume pointin to /home/jenkins/ not /home/jenkins/.jenkins

from docker-agent.

+1. Having this issue. Still need this fixed. for now i am creating my own jenkins slaves FROM openjdk:8-jdk-alpine. Id really like to be able to go back to the community jenkins

from docker-agent.

This introduces a regression in docker-slaves-plugin as the workspace is not available from other containers in the build environment

from docker-agent.