When I build a job using Multibranch pipeline, Jenkins is not creating workspace repository which is more than 32 character. It trims the character from starting of the job name.
Job name: multi-branch-jenkins-pipeline
Branch: Dev
what i want jenkins to create workspace: multi-branch-jenkins-pipeline_dev
what Jenkins create: iple-branch-jenkins-pipeline_dev
What i tried Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=40 Didn’t Work
I’m very curious why the directory it builds in matters to you
did you mean -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=40?
how did you set it? like what file, cli, etc
Inside /etc/sysconfig/jenkis
JAVA_ARGS=“-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=40” OR
JENKINS_JAVA_OPTIONS=“-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=40”
Are you usinga recent version of jenkins?
Hi ypappu926,
Jenkins 2.332.1 switched Jenkins from using System V init to use systemd with its Linux package installers for Debian, Ubuntu, Red Hat, Alma, openSUSE, Rocky, and more. The LTS Upgrade Guide describes that transition and how to adapt your environment to the transition.
There is a blog post about it as well at
There is also a video introduction for RPM based distributions like Red Hat Enterprise Linux, Alma Linux, Rocky Linux, Oracle Linux, and Amazon Linux.
There is also a video introduction for deb based distributions like Debian and Ubuntu
I am using Jenkins 2.361.3
361 is newer than 335. So follow the links I provided. Etc sysconfig is no longer used. I’m not sure why you seem to be ignoring half my responses.
I followed these links, but not working for me. Can you please tell me what script i add and where?
can you goto $JENKINS_URL/manage/systemInfo and confirm the property you set is listed there?
Looks like PATH_MAX is deprecated. Try MAX_LENGTH
However the core question was asked earlier: why do you need the workspace name to match the job name?
On one hand, the limit is there for portability - various OSes limit the lengths of path components and full path names, so allowing names too long opens the door for failed builds just because files in a deeply nested workspace may no longer be addressed.
On another, predictable names are an attack vector, potentially. Though I don’t think Jenkins deliberately “protects” from that.
In case of allowed parallel builds, you would have several workspaces instantiated with similar-looking but different names (often “prefix@number”), and in case of branch builds (as with MBPs) part of the name will refer to the branch name, PR number, etc.
There could have been various algorithms to craft the unique directory name over time, but generally it takes the tail of the build identifier (job name + number) as a more likely varied character sequence than a start of same string, and might pepper with random chars like mktemp would.
All that said, there is a place in the ecosystem for persistent workspaces, maybe even such that pass some sort of “state” files between rebuilds (infra jobs, stats, whatever). While this is better tracked elsewhere (DB, fileserver), a Jenkins workspace might be used for the purpose. In that case you should not really care about the particular name (might add a conveniently named symlink to the directory if something outside Jenkins needs to tap into the directory), but should take care to disable parallel builds so “prefix@2” etc. are not used - thus ignoring the pre-history state you try to pass around.
