[JIRA] (JENKINS-48067) workspace-volume should be optional

Hello,

We also have the same issue and while trying a lot of workarounds, we didn't manage to redirect the workspace to another directory while getting Jenkins to run in a non emptyDir volume.

Persistent volume is not the solution to our problem as it adds more complexity to our clusters.

Please make it so we can disable this workspace automated volume creation. Hardcoding this and not letting users to change it is a huge drawback to use Kubernetes pods slaves.

Sincerely,

Raphael

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

shenshuangmin@gmail.com (JIRA)

unread,

Sep 7, 2018, 1:28:01 PM9/7/18

to jenkinsc...@googlegroups.com

Stanley Shen commented on

I am new to kubernetes plugin on jenkins, and unfortunately I am using a customized docker image, and I install something under my user(ubuntu), for example the rvm.

But when the pod is running, jenkins always try to install rvm because of it cannot find rvm related things under the home path of ubuntu user.

It takes me quite lot time to figure out this fact that the home path of login user is mount by another emptyDir, thus the customization like rvm is always not there.

I agree this one is quite a huge drawback for user

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

jenkins-ci@carlossanchez.eu (JIRA)

unread,

Sep 7, 2018, 1:35:02 PM9/7/18

to jenkinsc...@googlegroups.com

Carlos Sanchez commented on

the workspace needs to be shared so all the containers can access for instance a git checkout

shenshuangmin@gmail.com (JIRA)

unread,

Sep 7, 2018, 1:44:01 PM9/7/18

to jenkinsc...@googlegroups.com

Stanley Shen commented on

Is there any suggestion about this, if I pre-install something, and there are configurations under /home/ubuntu folder in my case?

Thanks in advance.

las@dbc.dk (JIRA)

unread,

Dec 12, 2018, 8:37:03 AM12/12/18

to jenkinsc...@googlegroups.com

larsskj commented on

We're bitten by this as well: We really need to be able to preconfigure Jenkins home in the build containers we use.

If the rationale for mounting a shared volume is to have a shared workspace, why not simply move the movepoint to /home/jenkins/workspace?

In that way we could build an image with a preconfigured Jenkins home and yet have a shared workspace.

las@dbc.dk (JIRA)

unread,

Dec 12, 2018, 8:43:02 AM12/12/18

to jenkinsc...@googlegroups.com

larsskj edited a comment on

We're bitten by this as well: We really need to be able to preconfigure Jenkins home in the build containers we use.

If the rationale for mounting a shared volume is to have a shared workspace, why not simply move the movepoint mountpoint to /home/jenkins/workspace?

In that way we could build an image with a preconfigured Jenkins home and yet have a shared workspace.

rainer.weinhold@seitenbau.com (JIRA)

unread,

Dec 14, 2018, 3:38:02 AM12/14/18

to jenkinsc...@googlegroups.com

Rainer Weinhold commented on

Love the idea with mounting the subfolder /home/jenkins/workspace, or basically just allow configuring the mountpoint.

atomicrat2552@gmail.com (JIRA)

unread,

Mar 21, 2019, 2:40:03 PM3/21/19

to jenkinsc...@googlegroups.com

Jamison Greeley commented on

This just bit me too. I don't want anything from my workspace after my build step, as it's all contained in the container which is built at the start of every run. The plugin is mounting workspace-volume on top of my working directory, which wipes out my app's code, leading to a crash loop where rails aborts ( Gemfile not found ), kills the pod, Jenkins reschedules it (because the pod contains a terminated container), and this keeps going until I manually abort the build.

frangarciasalomon@gmail.com (JIRA)

unread,

Mar 26, 2019, 5:05:02 AM3/26/19

to jenkinsc...@googlegroups.com

Fran Garcia commented on

Sometime after my first comment this was fixed for us but recently this behavior has been regressed.

We are using Jenkins: 2.164.1. We thought the behavior had changed after updating to kubernetes-1.14.9, however we've tried downgrading it to 1.14.8 and the volume is still mounted over /home/jenkins. I don't see changes related to this issue on the changelog. Could this happen because of a change in a dependency?

bernardomk@gmail.com (JIRA)

unread,

Apr 30, 2019, 3:54:02 PM4/30/19

to jenkinsc...@googlegroups.com

Bernardo Corrêa commented on

Carlos Sanchez Wouldn't adding subPath solve the issue (under Secret Volume)? Then we would be able to specify a subpath and mount secrets as shown bellow:

 
                                                                volumeMounts:
 - name: jenkins
 mountPath: "/home/jenkins/.npmrc"
 subPath: npmrc
 readOnly: false 
 volumes:
 - name: jenkins
 secret:
 secretName: jenkins 
                                                            

We have a bunch of configuration that go under JENKINS_HOME. Would also be nice to be able to have SecurityContext.

Or if you have any suggestions on how to get around this issue...

Thanks in advance.

bernardomk@gmail.com (JIRA)

unread,

Apr 30, 2019, 3:54:04 PM4/30/19

to jenkinsc...@googlegroups.com

Bernardo Corrêa edited a comment on

[~csanchez] Wouldn't adding subPath solve the issue (under Secret Volume)? Then we would be able to specify a subpath and mount secrets as shown bellow:

{code:java}

volumeMounts:
- name: jenkins
mountPath: "/home/jenkins/.npmrc"
subPath: npmrc
readOnly: false
volumes:
- name: jenkins
secret:

secretName: jenkins{code}

We have a bunch of configuration that go files under JENKINS_HOME. Would also be nice to be able to have SecurityContext.

Or if you have any suggestions on how to get around this issue...

Thanks in advance.

bernardomk@gmail.com (JIRA)

unread,

Apr 30, 2019, 4:07:09 PM4/30/19

to jenkinsc...@googlegroups.com

Bernardo Corrêa edited a comment on

[~csanchez] Wouldn't adding subPath solve the issue (under Secret Volume)? Then we would be able to specify a subpath and mount secrets as shown bellow:

{code:java}
volumeMounts:
- name: jenkins
mountPath: "/home/jenkins/.npmrc"
subPath: npmrc
readOnly: false
volumes:
- name: jenkins
secret:
secretName: jenkins{code}

We have a bunch of configuration files under JENKINS_HOME. Would also be nice to be able to have SecurityContext.

Or if you have any suggestions on how to get around this issue...

Or allowing users to change from emptyDir to secret or ConfigMap...

Thanks in advance.

jglick@cloudbees.com (JIRA)

unread,

Jul 16, 2019, 3:44:00 PM7/16/19

to jenkinsc...@googlegroups.com

Jesse Glick assigned an issue to Unassigned

Jenkins /

workspace-volume should be optional

Change By:	Jesse Glick
Assignee:	Carlos Sanchez

regs@akom.net (JIRA)

unread,

Nov 14, 2019, 2:28:03 PM11/14/19

to jenkinsc...@googlegroups.com

Alexander Komarov commented on

Like many people here I pre-configure my docker images with everything including the WORKDIR/tools directory (maven, gradle, groovy, etc). This works great with the docker plugin, not so much with k8s.

My current workaround is to move tools in my ENTRYPOINT script if this is k8s (my images are also used outside of k8s)

 
                                                                NORMAL_WORKDIR=/data/jenkins-slave
if [ -n "$JENKINS_AGENT_WORKDIR" ] && [ "$JENKINS_AGENT_WORKDIR" != "$NORMAL_WORKDIR" ] ; then
  echo "Moving preinstalled Jenkins tools into the active workdir: $JENKINS_AGENT_WORKDIR"
  mv $NORMAL_WORKDIR/tools $JENKINS_AGENT_WORKDIR/
fi
 
                                                            

(My ENTRYPOINT script is a wrapper around /usr/local/bin/jenkins-slave)

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

regs@akom.net (JIRA)

unread,

Nov 14, 2019, 2:29:04 PM11/14/19

to jenkinsc...@googlegroups.com

Alexander Komarov edited a comment on

Like many people here I pre-configure my docker images with everything including the autoinstalled contents of the [ WORKDIR ] /tools directory (maven, gradle, groovy, etc). This works great with the docker plugin, not so much with k8s.

My current workaround is to move tools in my ENTRYPOINT script if this is k8s (my images are also used outside of k8s)

{code:java}

NORMAL_WORKDIR=/data/jenkins-slave
if [ -n "$JENKINS_AGENT_WORKDIR" ] && [ "$JENKINS_AGENT_WORKDIR" != "$NORMAL_WORKDIR" ] ; then
echo "Moving preinstalled Jenkins tools into the active workdir: $JENKINS_AGENT_WORKDIR"
mv $NORMAL_WORKDIR/tools $JENKINS_AGENT_WORKDIR/
fi

{code}

(My ENTRYPOINT script is a wrapper around /usr/local/bin/jenkins-slave)

regs@akom.net (JIRA)

unread,

Nov 14, 2019, 3:31:03 PM11/14/19

to jenkinsc...@googlegroups.com

Alexander Komarov edited a comment on

Like many people here I pre-configure my docker images with everything including the autoinstalled contents of the [WORKDIR]/tools directory (maven, gradle, groovy, etc). This works great with the docker plugin, not so much with k8s.

My current workaround is to move symlink the tools directory into the Working Directory in my ENTRYPOINT script if this is when running in k8s (my images are also used outside of k8s)

{code:java}
NORMAL_WORKDIR=/data/jenkins-slave
if [ -n "$JENKINS_AGENT_WORKDIR" ] && [ "$JENKINS_AGENT_WORKDIR" != "$NORMAL_WORKDIR" ] ; then

echo " Moving Linking preinstalled Jenkins tools into the active workdir: $JENKINS_AGENT_WORKDIR"
mv ln -s $NORMAL_WORKDIR/tools $JENKINS_AGENT_WORKDIR/

fi
{code}
(My ENTRYPOINT script is a wrapper around /usr/local/bin/jenkins-slave)

rainer.weinhold@seitenbau.com (JIRA)

unread,

Nov 15, 2019, 3:41:05 AM11/15/19

to jenkinsc...@googlegroups.com

Rainer Weinhold commented on

For me a part got 'fixed' when in one of the last Versions the EmptyDirectory got mounted at ~/agent instead of the ~ directory.

But this won't fix the tools case. Which i'm currently not using, but I want, because of performance (time + traffic) issues, when with every new container Jenkins needs to download all tools again. Would it be possible to change the tools root folder to somthing like "~/agent-tools" ?