The whole build agent root directory is managed as a docker volume, and
retrieved from previous build, so you can easily benefit such caching if
you configure maven to use adequate path for local repository (which should
be the case by default, as /home/jenkins is slave root).
We also considered to offer an option to cache some path, comparable to
travis-ci approach (based on tar.gz), so typically let end-user configure
maven local repository as "cached". Backed could rely on additional volumes
for this purpose, but definitively not on bind-mounts :P. This would let us
investigate scalability challenge to distribute such a cache, maybe just by
relying on docker volume-plugin features (but then relying on proprietary
API), or maybe by using jenkins as a volume replication facility, *à la*
Le dimanche 16 octobre 2016 00:44:12 UTC+2, Qiang a écrit :
> Hi, Nicolas,
> One example I can think of: for maven build, we want to cache the
> downloaded dependencies so we don't have to download them every time.
> So in that case, I was thinking to cache on the host, or a data volume.
> Any suggestions?
> On Saturday, October 15, 2016 at 11:59:08 AM UTC-5, Qiang wrote:
>> Thank you for posting the response ! I do need to rethink my strategy
>> now. Even though I need to solve legacy problems in a short term , I agree
>> that it does not become a requirement :)
>> So for moving data between containers , what options can I explore ? And
>> is there instruction to use side containers ? I was not able to find much
>> There's no technical limitation to use this option (we actually already
>> support it to allow docker.sock bind mount on a dedicated side container),
>> but our experience is most user use this for bind-mount, which result in
>> permission issues and in most case are just short terms workarounds to
>> introduce bad practices. So we decided *not* to expose this option to
>> IIUC your use case (from some private email) some legacy jobs you run
>> rely on a NFS server to host project dependencies. Relying on a bind mount
>> would make your build fragile and non-reproducible. You better should
>> create a project specific docker image, to include those dependencies
>> (assuming you can't update your build script to a modern dependency
>> resolution approach).
>> For sure this require some effort to migrate your builds, but I can't
>> consider "*legacy bad practice*" as a valid use-case :P
>> Le vendredi 14 octobre 2016 15:55:01 UTC+2, Qiang a écrit :
>>> How can I set container options to the Docker slave such as volume
>>> settings? I need to mount a host directory to the container.
>>> So far, the only option I can see is to define the slave container
>>> image, and side container image as following:
>>> dockerNode(image: "maven:3.3.3-jdk-8", sideContainers:
>>> How do I pass "-v" or "--volumes-from" to the slave container?
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 view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.