Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38706

Workspace directory names mangled in multibranch pipeline

      Apparently after a recent update of plugins, our Multibranch Pipeline jobs started putting their workspaces in mangled locations. They used to be, for example, in D:\jenkins\cm-jenkins-09\my-pipline-job\my-branch-name and now they're like D:\jenkins\cm-jenkins-09\ine-job_my-banch-name-5P5URKHPJXWGGVIWDQOJBB3N7RJECAQJGFTDCVOPY3PABO7LNTIQ

      There are several problems with this:

      1. They're difficult to read with all that garbage at the end, and the beginning of the name sometimes cut off
      2. They're not organized within the parent job like they used to be
      3. This is causing files within them to have extremely long paths such that Windows won't actually let us delete them (Jenkins, CMD, and Windows Explorer all fail to delete them)

      Let me know if I can provide any other information to help solve this. This is a private Jenkins install so I can't point you to it.

          [JENKINS-38706] Workspace directory names mangled in multibranch pipeline

          David Beck added a comment - - edited

          MSBuild does not support long file path names FYI Git does support long file paths but will break powershell and other command unless you use the //? access paths which almost no one does normally.

          This i a feature breaking bug that should be fixed sooner than later.

          David Beck added a comment - - edited MSBuild does not support long file path names FYI Git does support long file paths but will break powershell and other command unless you use the //? access paths which almost no one does normally. This i a feature breaking bug that should be fixed sooner than later.

          The only fix I found is to revert multibranch and related plugins to the version before september updates. This is a must fix for build to work in windows environments as well compatibility with previous builds.

          Alexander Siniouguine added a comment - The only fix I found is to revert multibranch and related plugins to the version before september updates. This is a must fix for build to work in windows environments as well compatibility with previous builds.

          Greg Smith added a comment -

          I do understand why people are upset by this change.

          However, if you want the original behavior, you can set the below as an option on your jenkins java vm setup (for example, in /etc/default/jenkins)

          -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0
          

          Setting this back to the original behavior has generally satisfied us: I hope this option is not removed. But for those which this changed caused a problem, the above is a pretty OK solution (IMO)

          Greg Smith added a comment - I do understand why people are upset by this change. However, if you want the original behavior, you can set the below as an option on your jenkins java vm setup (for example, in /etc/default/jenkins) -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 Setting this back to the original behavior has generally satisfied us: I hope this option is not removed. But for those which this changed caused a problem, the above is a pretty OK solution (IMO)

          Greg Smith added a comment -

          Also, I can confirm that msbuild does not work with long file names, even in those versions of Windows 10 where it has been enabled at the filesystem level.

          Greg Smith added a comment - Also, I can confirm that msbuild does not work with long file names, even in those versions of Windows 10 where it has been enabled at the filesystem level.

          Hi, when activating -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 (running on Windows platform), I get 3 folders created for every branch:

          • projectname_branchname-C5MAL5QJSBT3VC7KWLCI3CTGCJVURIOQAGAQA2TXJGASFJP5755A
          • projectname_branchname-C5MAL5QJSBT3VC7KWLCI3CTGCJVURIOQAGAQA2TXJGASFJP5755A@script
          • projectname_branchname-C5MAL5QJSBT3VC7KWLCI3CTGCJVURIOQAGAQA2TXJGASFJP5755A@tmp
            when Jenkins pipeline is running Jenkinsfile, shell scripts are executed in the 1st one which is empty, while the code has been checked out in the one ending with @script
            Is this a side effect of this or related to another defect ? Thanks

          nicolas mettais added a comment - Hi, when activating -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 (running on Windows platform), I get 3 folders created for every branch: projectname_branchname-C5MAL5QJSBT3VC7KWLCI3CTGCJVURIOQAGAQA2TXJGASFJP5755A projectname_branchname-C5MAL5QJSBT3VC7KWLCI3CTGCJVURIOQAGAQA2TXJGASFJP5755A@script projectname_branchname-C5MAL5QJSBT3VC7KWLCI3CTGCJVURIOQAGAQA2TXJGASFJP5755A@tmp when Jenkins pipeline is running Jenkinsfile, shell scripts are executed in the 1st one which is empty, while the code has been checked out in the one ending with @script Is this a side effect of this or related to another defect ? Thanks

          Philip O'Gorman added a comment - - edited

          gregcovertsmith nim

          How do it add this setting on a windows Jenkins install?

          -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0

          Do I add it to the jenkins.xml file?

           

          <arguments>-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0</arguments>

           

          I got it to work by typing the following in to the  groovy script console, but how do I make sure its set on start up?

           

          jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0

           

          Philip O'Gorman added a comment - - edited gregcovertsmith nim How do it add this setting on a windows Jenkins install? -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 Do I add it to the jenkins.xml file?   <arguments>-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0</arguments>   I got it to work by typing the following in to the  groovy script console, but how do I make sure its set on start up?   jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0  

          Gerbrand Stap added a comment -

          We run Jenkins as a service on Windows and there the parameter must be added to <arguments> in jenkins.xml.

          That makes our arguments tag look like this:

          <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 -jar "%BASE%\jenkins.war" --httpPort=8080 --webroot="%BASE%\war"</arguments>
          

          (the rest was already in there)

          Gerbrand Stap added a comment - We run Jenkins as a service on Windows and there the parameter must be added to <arguments> in jenkins.xml. That makes our arguments tag look like this: <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 -jar "%BASE%\jenkins.war" --httpPort=8080 --webroot= "%BASE%\war" </arguments> (the rest was already in there)

          gstapviadata thanks, I couldn't find the info anywhere, much appreciated!

          Philip O'Gorman added a comment - gstapviadata thanks, I couldn't find the info anywhere, much appreciated!

          Maksim Melnikov added a comment - - edited

          Hi everyone!
          I`ve got problem with Jenkins paths and cmake:

          CMake Error at /opt/tools/common.toolchain.cmake:449 (add_custom_target):
            The target name
            "_var_jenkins_home_workspace_n_feature-SW_EN-208-jenkins-G4FWLCUHTMHI23I7XTJIZIYQ4LYV2G7DLKU6TNRUTURI4LDBWIIA@2_deps_atlas-bld_cygwin64_utst_iris_text-2d_texture_texture-fonts_guikit_atlas1_atlas1"
            is reserved or not valid for certain CMake features, such as generator
            expressions, and may result in undefined behavior.
          

          I think that it`s because there is "@" in directory name. So cmake fails the build
          How can I make Jenkins to stop using "@" in names, anybody?

           

          UPD:

          Option -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 helps me. Thanks.

           

          Maksim Melnikov added a comment - - edited Hi everyone! I`ve got problem with Jenkins paths and cmake: CMake Error at /opt/tools/common.toolchain.cmake:449 (add_custom_target): The target name "_var_jenkins_home_workspace_n_feature-SW_EN-208-jenkins-G4FWLCUHTMHI23I7XTJIZIYQ4LYV2G7DLKU6TNRUTURI4LDBWIIA@2_deps_atlas-bld_cygwin64_utst_iris_text-2d_texture_texture-fonts_guikit_atlas1_atlas1" is reserved or not valid for certain CMake features, such as generator expressions, and may result in undefined behavior. I think that it`s because there is " @ " in directory name. So cmake fails the build How can I make Jenkins to stop using " @ " in names, anybody?   UPD: Option -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0  helps me. Thanks.  

          pleemann added a comment -

          I have the same problem as mamelnikov had: the "@" sign jenkins adds to workspace paths of parallel nodes in a pipeline breaks build tools. Setting

          jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0
          

          did not help. Any way to tell jenkins not to use the "@" sign, but e.g. underscore instead?

          pleemann added a comment - I have the same problem as mamelnikov had: the "@" sign jenkins adds to workspace paths of parallel nodes in a pipeline breaks build tools. Setting jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 did not help. Any way to tell jenkins not to use the "@" sign, but e.g. underscore instead?

          Ben Middleton added a comment -

          For our setup, setting jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 had some side effects when using the Pipeline Maven plugin. In particular, we were seeing:

          [ERROR] The specified user settings file does not exist: c:\hudson\workspace\UDP\tcdl\hotfixcleanF8.1.
          1cleanFCRQ-6100@tmp\withMaven19741b98\settings.xml
          ERROR: [withMaven] WARNING Exception parsing the logs generated by the Jenkins Maven Event Spy c:\hudson\workspace\UDP\tcdl\hotfix%2F8.1.1%2FCRQ-6100@tmp\withMaven19741b98\maven-spy-20170904-153723-126.log, ignore file.  Please report a bug associated for the component 'pipeline-maven-plugin' at https://issues.jenkins-ci.org 
          

          Ben Middleton added a comment - For our setup, setting jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 had some side effects when using the Pipeline Maven plugin. In particular, we were seeing: [ERROR] The specified user settings file does not exist: c:\hudson\workspace\UDP\tcdl\hotfixcleanF8.1. 1cleanFCRQ-6100@tmp\withMaven19741b98\settings.xml ERROR: [withMaven] WARNING Exception parsing the logs generated by the Jenkins Maven Event Spy c:\hudson\workspace\UDP\tcdl\hotfix%2F8.1.1%2FCRQ-6100@tmp\withMaven19741b98\maven-spy-20170904-153723-126.log, ignore file. Please report a bug associated for the component 'pipeline-maven-plugin' at https: //issues.jenkins-ci.org

          Hans Bogaards added a comment -

          I must be missing something, but it seems that all issues that are related to this are close as 'duplicate'!

          None of them have a real solution, just some workarounds

          Hans Bogaards added a comment - I must be missing something, but it seems that all issues that are related to this are close as 'duplicate'! None of them have a real solution, just some workarounds

          Øyvind R added a comment -

          As the above commenter noted, none of the issues regarding this have actually been addressed. They have only been marked as duplicates of one another, and closed. I'm reopening this one so that a resolution can be found.

          Øyvind R added a comment - As the above commenter noted, none of the issues regarding this have actually been addressed. They have only been marked as duplicates of one another, and closed. I'm reopening this one so that a resolution can be found.

          Facing the same issue - even on non multi-branch pipeline there are created workspace directories with suffixes like:

          @2

          @2tmp

          @script

          @script@tmp

          @tmp

          Constantin Bugneac added a comment - Facing the same issue - even on non multi-branch pipeline there are created workspace directories with suffixes like: @2 @2tmp @script @script@tmp @tmp

          pleemann added a comment -

          A (hacky) workaround for this, using scripted pipelines:

           

          def wrappedWorkspace(body) {
              node {
                  if(env.WORKSPACE.contains("@")) {
                      ws (env.WORKSPACE.replace("@", "__")) {
                          body()
                      }
                  }else{
                      body()
                  }
              }
          }
          

          pleemann added a comment - A (hacky) workaround for this, using scripted pipelines:   def wrappedWorkspace(body) { node { if (env.WORKSPACE.contains( "@" )) { ws (env.WORKSPACE.replace( "@" , "__" )) { body() } } else { body() } } }

          Constantin Bugneac added a comment - - edited

          Thanks pleemann, tried on Jenkins 2.91 but it still does create a new workspace with @3 suffix instead of the one specified in ws().

          Constantin Bugneac added a comment - - edited Thanks pleemann , tried on Jenkins 2.91 but it still does create a new workspace with @3 suffix instead of the one specified in ws().

          This issue seems to occur when you do have any aborted job on your queue.

          What I did to stop it was to find out which build number was aborted then I removed the respective folder then I restarted Jenkins. After that Jenkins started to recreate the path in right way, without '@' or or numbers

           

          Eduardo Fonseca added a comment - This issue seems to occur when you do have any aborted job on your queue. What I did to stop it was to find out which build number was aborted then I removed the respective folder then I restarted Jenkins. After that Jenkins started to recreate the path in right way, without '@' or or numbers  

          eduardofesilva in my case I don't have any (manually) aborted jobs but I do have failed jobs from previous runs.

          Constantin Bugneac added a comment - eduardofesilva in my case I don't have any (manually) aborted jobs but I do have failed jobs from previous runs.

          cb_tes_global try to use the same approach it might works as well and let me know if that woked for you

          Eduardo Fonseca added a comment - cb_tes_global try to use the same approach it might works as well and let me know if that woked for you

          Øyvind R added a comment -

          Just a note to anyone who might be working on this: This isn't only about the "@" in the folder names, it is a general problem that the folder names are extremely long and unwieldy. All logs tend to become near unreadable as soon as they mention a file path.

          Øyvind R added a comment - Just a note to anyone who might be working on this: This isn't only about the "@" in the folder names, it is a general problem that the folder names are extremely long and unwieldy. All logs tend to become near unreadable as soon as they mention a file path.

          This is causing my builds to fail because the foldername starts with a - and a command called by dpkg takes the folder as argument but thinks that the folder is actually another flag. Example: dpkg-source --before-build -Foldername

          Hermann Schweizer added a comment - This is causing my builds to fail because the foldername starts with a - and a command called by dpkg takes the folder as argument but thinks that the folder is actually another flag. Example: dpkg-source --before-build -Foldername

          connor poole added a comment -

          We have the same problem as hermain these folder names should really start with the proper git name and then end with random characters... rather than the current behavior which truncates the git repo name first

          connor poole added a comment - We have the same problem as hermain these folder names should really start with the proper git name and then end with random characters... rather than the current behavior which truncates the git repo name first

          David Wagner added a comment -

          I got here because I would like to have two different multibranch pipeline jobs share the same workspace for a same branch. If I call ws(env.BRANCH_NAME) in both of my Jenkinsfile, it does the trick but when the branch is deleted, the multibranch pipeline scan will only delete the default workspace and not the custom workspace leaving the sources and the build artifacts on the node.

          Most other job types have a customWorkspace api that let the user define what the workspace should be. i understand that it can't be that simple for a multi-branch pipeline but maybe a custom workspace name template would work.

          David Wagner added a comment - I got here because I would like to have two different multibranch pipeline jobs share the same workspace for a same branch. If I call ws(env.BRANCH_NAME) in both of my Jenkinsfile, it does the trick but when the branch is deleted, the multibranch pipeline scan will only delete the default workspace and not the custom workspace leaving the sources and the build artifacts on the node. Most other job types have a customWorkspace api that let the user define what the workspace should be. i understand that it can't be that simple for a multi-branch pipeline but maybe a custom workspace name template would work.

          deubeuliou, how is your problem related to this bug? If it is not please open another ticket.

          Aurélien Bertron added a comment - deubeuliou , how is your problem related to this bug? If it is not please open another ticket.

          On Linux this also creates the problem that shebangs that then include this path get too long and thus scripts (e.g. in python virtualenvs in that build location) cannot be executed.

          Martin Häcker added a comment - On Linux this also creates the problem that shebangs that then include this path get too long and thus scripts (e.g. in python virtualenvs in that build location) cannot be executed.

          jaeyun jeong added a comment -

          Why is this hash code behind the folder name? is that collision between branches? So, Why does not  jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 have any problems? Please let me know.... 

          jaeyun jeong added a comment - Why is this hash code behind the folder name? is that collision between branches? So, Why does not   jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 have any problems? Please let me know.... 

          Dalmo Santos added a comment - - edited

          Hi!
          I found a palliative solution to the problem. I added the Allocate Workspace.  It works on multibranch pipeline, on any node.

          Ex.:
          def wsDir = "/some/path/${env.BRANCH_NAME}"
          ws (wsDir) {
          // some block
          }

          Dalmo Santos added a comment - - edited Hi! I found a palliative solution to the problem. I added the Allocate Workspace.  It works on multibranch pipeline, on any node. Ex.: def wsDir = "/some/path/${env.BRANCH_NAME}" ws (wsDir) { // some block }

          Danny Tamsen added a comment -

          dalmosantos _> Another possible solution is to utilize the 'customWorkspace' element as mentioned earlier. It would look something like: 

           

          agent{
            node{
              label 'my-node-label'
              customWorkspace "MyFixedLocation/MyPipelineName_${BRANCH_NAME}"
            }
          }
          

          Danny Tamsen added a comment - dalmosantos _> Another possible solution is to utilize the 'customWorkspace' element as mentioned earlier. It would look something like:    agent{ node{ label 'my-node-label' customWorkspace "MyFixedLocation/MyPipelineName_${BRANCH_NAME}" } }

          Using 

          customWorkspace "${JENKINS_HOME}/Workspace/${URLDecoder.decode(JOB_NAME)}/${BUILD_NUMBER}"
          

          Due to this change got some issues with c++ msbuild prebuild triggered scripts but managed to fix those

          Jakub Pawlinski added a comment - Using  customWorkspace "${JENKINS_HOME}/Workspace/${URLDecoder.decode(JOB_NAME)}/${BUILD_NUMBER}" Due to this change got some issues with c++ msbuild prebuild triggered scripts but managed to fix those

          Adam Daughterson added a comment - - edited

          After upgrade to this crufty new version of pipeline, all multibranch pipelines using older (eg no declarative pipeline stuffs like pipeline{} agent{} etc) syntax have now a useless name for the git repo, and first part of the name is truncated instead of the ending. Setting jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 has no noticeable effect. Combining new and old syntax does not appear to get beyond carving a workspace, and attempting to set workspace via customWorkspace doesn't work at all.

          Who approved this disruptive myopic change? Way to break everything...

          Adam Daughterson added a comment - - edited After upgrade to this crufty new version of pipeline, all multibranch pipelines using older (eg no declarative pipeline stuffs like pipeline{} agent{} etc) syntax have now a useless name for the git repo, and first part of the name is truncated instead of the ending. Setting jenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 has no noticeable effect. Combining new and old syntax does not appear to get beyond carving a workspace, and attempting to set workspace via customWorkspace doesn't work at all. Who approved this disruptive myopic change? Way to break everything...

          An acceptable workaround would be a flag to opt out of the workspace name mangling in either the Jenkinsfile or the multibranch configuration.

          Adam Daughterson added a comment - An acceptable workaround would be a flag to opt out of the workspace name mangling in either the Jenkinsfile or the multibranch configuration.

          We are using custom workspace but this is causing trouble with third party tools which do not know that custom workspaces exists.

          Zangdaarr Mortpartout added a comment - We are using custom workspace but this is causing trouble with third party tools which do not know that custom workspaces exists.

          Jerome Mohanan added a comment - - edited

          Cant use the workaround in my case. I don't use docker, I build directly on a build server VM (Windows)

          agent{
             node{
               label 'my-node-label'
               customWorkspace "MyFixedLocation/MyPipelineName_${BRANCH_NAME}"
             }
          }

          In my case, I can't specify label field, so not possible to specify customWorkspace. Any other workarounds please.

          Jerome Mohanan added a comment - - edited Cant use the workaround in my case. I don't use docker, I build directly on a build server VM (Windows) agent{ node{ label 'my-node-label' customWorkspace "MyFixedLocation/MyPipelineName_${BRANCH_NAME}" } } In my case, I can't specify label field, so not possible to specify customWorkspace. Any other workarounds please.

          Mike Ellery added a comment -

          this completely breaks my windows builds because of the 260 limit. Why can't you use the github short hash instead?

          Mike Ellery added a comment - this completely breaks my windows builds because of the 260 limit. Why can't you use the github short hash instead?

          Daan Timmer added a comment -

          This is also a huge issue here. Where it is blocking us from properly using the multibranch pipeline feature.

          Daan Timmer added a comment - This is also a huge issue here. Where it is blocking us from properly using the multibranch pipeline feature.

          Alp Dener added a comment - - edited

          Also huge issue for us. The mangled and shortened names often produce paths that start with a dash character, and that breaks many configure and build scripts in a variety of projects.

          The fact that this is an almost two year old issue that is still unresolved is pretty ridiculous.

          Alp Dener added a comment - - edited Also huge issue for us. The mangled and shortened names often produce paths that start with a dash character, and that breaks many configure and build scripts in a variety of projects. The fact that this is an almost two year old issue that is still unresolved is pretty ridiculous.

          Oleg Nenashev added a comment -

          svanoort abayer rsandell Hi. Is it in the scope for the Pipeline team? godskalk has recently raised JENKINS-52911 to get some attention to it

          Oleg Nenashev added a comment - svanoort abayer rsandell Hi. Is it in the scope for the Pipeline team? godskalk has recently raised JENKINS-52911 to get some attention to it

          Jesse Glick added a comment -

          Yes the current behavior is intentional. Certainly it has some problems that affect some people; the previous behavior also had serious problems that affected lots of people.

          Rather than applying further tweaks, the basic assumption—that a workspace path on an agent (relative to the agent’s “filesystem root”) must be a function of the job’s full name so that it is guaranteed to be unique—should be discarded, in favor of a system of allocating short, legible workspace paths per job × agent and explicitly tracking them.

          This could be integrated with proper workspace cleanup (for “permanent, as opposed to elastic, agents), which Jenkins has never done, which is why I proposed such a rewrite in JENKINS-2111.

          Jesse Glick added a comment - Yes the current behavior is intentional. Certainly it has some problems that affect some people; the previous behavior also had serious problems that affected lots of people. Rather than applying further tweaks, the basic assumption—that a workspace path on an agent (relative to the agent’s “filesystem root”) must be a function of the job’s full name so that it is guaranteed to be unique—should be discarded, in favor of a system of allocating short, legible workspace paths per job × agent and explicitly tracking them. This could be integrated with proper workspace cleanup (for “permanent, as opposed to elastic, agents), which Jenkins has never done, which is why I proposed such a rewrite in JENKINS-2111 .

          Aaron D. Marasco added a comment - - edited

          We just ran into a problem where the name of our git branch is "feature--XXX" and Jenkins decided the name was too long, so stripped feature. Leaving a directory that starts with "--".

           

          13:22:18 [CentOS 6: Main RPM Build] Found files starting with hyphen
          13:22:18 [CentOS 6: Main RPM Build] error: Bad exit status from /var/tmp/rpm-tmp.mTAEkR (%install)
           

          Aaron D. Marasco added a comment - - edited We just ran into a problem where the name of our git branch is "feature--XXX" and Jenkins decided the name was too long, so stripped feature. Leaving a directory that starts with "--".   13:22:18 [CentOS 6: Main RPM Build] Found files starting with hyphen 13:22:18 [CentOS 6: Main RPM Build] error: Bad exit status from / var /tmp/rpm-tmp.mTAEkR (%install)

          Stephen Connolly added a comment - - edited

          I'm adding some tweaks to the implementation in a PR.

          • Each agent's system properties will also be checked for a local override of path max. This will allow windows agents to have a shorter path max without affecting *nix agents
          • I am adding a second implementation that uses the NameMangler. As NameMangler should always produce a safe name for all OSes (but it might be too long on windows if your SCM checkout is too deep... nothing we can do there) it is a simple boolean flag to enable/disable. And as it is opinionated it can only be set globally. System property will be jenkins.branch.WorkspaceLocatorV2Impl.ENABLE I suspect that the NameMangler version is the one people actually want, so before I default it on I would appreciate some real world feed-back

          Stephen Connolly added a comment - - edited I'm adding some tweaks to the implementation in a PR . Each agent's system properties will also be checked for a local override of path max. This will allow windows agents to have a shorter path max without affecting *nix agents I am adding a second implementation that uses the NameMangler . As NameMangler should always produce a safe name for all OSes (but it might be too long on windows if your SCM checkout is too deep... nothing we can do there) it is a simple boolean flag to enable/disable. And as it is opinionated it can only be set globally. System property will be jenkins.branch.WorkspaceLocatorV2Impl.ENABLE I suspect that the NameMangler version is the one people actually want, so before I default it on I would appreciate some real world feed-back

          stephenconnolly I didn't see anything in that PR addressing a possible leading "-" - are you assuming the path length should fix "most" cases? That's the problem I had as well as others previously (e.g. dener). Otherwise, kudos and thanks!

          Aaron D. Marasco added a comment - stephenconnolly I didn't see anything in that PR addressing a possible leading "-" - are you assuming the path length should fix "most" cases? That's the problem I had as well as others previously ( e.g. dener ). Otherwise, kudos and thanks!

          Jesse Glick added a comment -

          This is just beating around the bush. See JENKINS-2111 for the proper permanent solution to handling inelastic (“dumb”) build agents.

          Jesse Glick added a comment - This is just beating around the bush. See JENKINS-2111 for the proper permanent solution to handling inelastic (“dumb”) build agents.

          Josh Trow added a comment -

          Unless in that corresponding XML file you're holding a mapping of what the paths are today to some shorter friendly your name that is then used in actuality I'm still not sure how that resolves the issue of the workspace having a path that has a 'mangled' name. I agree that having better logic around work spaces and the ability to clean them up automatically is a good thing but I don't think it's directly related to this nor will one automatically solve the other (depending on the implementation it could)

          Josh Trow added a comment - Unless in that corresponding XML file you're holding a mapping of what the paths are today to some shorter friendly your name that is then used in actuality I'm still not sure how that resolves the issue of the workspace having a path that has a 'mangled' name. I agree that having better logic around work spaces and the ability to clean them up automatically is a good thing but I don't think it's directly related to this nor will one automatically solve the other (depending on the implementation it could)

          Jesse Glick added a comment -

          in that corresponding XML file you're holding a mapping of what the paths are today to some shorter friendly your name

          This. Read what I wrote.

          Jesse Glick added a comment - in that corresponding XML file you're holding a mapping of what the paths are today to some shorter friendly your name This. Read what I wrote.

          Josh Trow added a comment -

          I did read what you wrote, hence my question - nothing in this:

          Each node (master, agent) should just pay attention to when a workspace is used. (If in core, via WorkspaceList; otherwise, perhaps via WorkspaceListener.) Then record a workspaces.xml, a sibling of workspace/, with a list of records: relative workspace path, Item.fullName, timestamp.

          seems to say that you are intending to 'clean' or 'modify' or 'change' the paths from what they are today to anything nicer - just that you want to maintain a map of job to workspace for cleanup purposes down the road.

          Josh Trow added a comment - I did read what you wrote, hence my question - nothing in this: Each node (master, agent) should just pay attention to when a workspace is used. (If in core, via  WorkspaceList ; otherwise, perhaps via  WorkspaceListener .) Then record a  workspaces.xml , a sibling of  workspace/ , with a list of records: relative workspace path,  Item.fullName , timestamp. seems to say that you are intending to 'clean' or 'modify' or 'change' the paths from what they are today to anything nicer - just that you want to maintain a map of job to workspace for cleanup purposes down the road.

          Jesse Glick added a comment -

          Sorry, that was a corollary that should have been made explicit: if you are maintaining a persistent mapping of this kind, then the need to include some manner of hash in the workspace path disappears. (You would still need to translate dangerous characters to something more neutral like _.)

          Jesse Glick added a comment - Sorry, that was a corollary that should have been made explicit: if you are maintaining a persistent mapping of this kind, then the need to include some manner of hash in the workspace path disappears. (You would still need to translate dangerous characters to something more neutral like _ .)

          Tommy McNeely added a comment -

          WORKAROUND

          • For users using python virtualenv, try using 
            virtualenv --relocatable venv

             

          ... BEFORE calling "pip"

           

          That changes the shebang line to:

          #!/usr/bin/env python27

           

          ... or whatever version of python you are using, but significantly shorter.

          Tommy McNeely added a comment - WORKAROUND For users using python virtualenv, try using  virtualenv --relocatable venv   ... BEFORE calling "pip"   That changes the shebang line to: #!/usr/bin/env python27   ... or whatever version of python you are using, but significantly shorter.

          kpop added a comment - - edited

          Removing the 'garbage' at the end causes name clashes (cf. JENKINS-54640). (edit: fixed issue link)

          kpop added a comment - - edited Removing the 'garbage' at the end causes name clashes (cf. JENKINS-54640 ). (edit: fixed issue link)

          Øyvind R added a comment -

          kpop, there is no way you need over 50 base-64 characters to avoid name clashes. Git manages with just 7 hex-characters for thousands of commits.

          Øyvind R added a comment - kpop , there is no way you need over 50 base-64 characters to avoid name clashes. Git manages with just 7 hex-characters for thousands of commits.

          kpop added a comment -

          godskalk, I agree: less is certainly better, but name clashes should be avoided.

          kpop added a comment - godskalk , I agree: less is certainly better, but name clashes should be avoided.

          sascha bates added a comment -

          My workaround for this was to define a jobName and then use the jobName in the workspace. The jobName var was also to account for feature branches and builds around several different microservices that might also have the same Jira id attached to them.

          Our feature branch work is all short lived and named feature/jira-12345-some-description. Our services are named my-service-name. The below lines result in a 'my-service-name-jira-12345' workspace name. 99% of the time we don't need to look at workspaces anyway, but this makes the console log readable as well as making it possible to write directory cleanup patterns based on naming.
           
           
           
          def jobName = JOB_NAME.replaceAll(/\/\w+%2F/,'-').toLowerCase()
          ansiColor( 'xterm' ) {
            timestamps {try {node() {
              ws( "workspace/${jobName}" ) {
                stage( 'Pull Github Repository' ) {
           

          sascha bates added a comment - My workaround for this was to define a jobName and then use the jobName in the workspace. The jobName var was also to account for feature branches and builds around several different microservices that might also have the same Jira id attached to them. Our feature branch work is all short lived and named feature/jira-12345-some-description. Our services are named my-service-name. The below lines result in a 'my-service-name-jira-12345' workspace name. 99% of the time we don't need to look at workspaces anyway, but this makes the console log readable as well as making it possible to write directory cleanup patterns based on naming.       def jobName = JOB_NAME.replaceAll(/\/\w+%2F/,'-').toLowerCase() ansiColor( 'xterm' ) {   timestamps { try { node() {     ws( "workspace/${jobName}" ) {       stage( 'Pull Github Repository' ) {  

          Jesse Glick added a comment -

          This issue became obsolete with the release of the fix of JENKINS-2111.

          Jesse Glick added a comment - This issue became obsolete with the release of the fix of JENKINS-2111 .

          Suemiao Rossignol added a comment - - edited

          I am using Jenkins 2.150.2 version but still  hitting this issue?

          I also install short workspace plugins without any luck.

          Is this truly fixed?

          Suemiao Rossignol added a comment - - edited I am using Jenkins 2.150.2 version but still  hitting this issue? I also install short workspace plugins without any luck. Is this truly fixed?

          Jesse Glick added a comment -

          suemiao please do not reopen. If necessary, file a separate (but linked) bug report with complete steps to reproduce from scratch as well as FINE logs from jenkins.branch.WorkspaceLocatorImpl.

          Jesse Glick added a comment - suemiao please do not reopen. If necessary, file a separate (but linked) bug report with complete steps to reproduce from scratch as well as FINE logs from jenkins.branch.WorkspaceLocatorImpl .

            Unassigned Unassigned
            tyrelh Tyrel Haveman
            Votes:
            76 Vote for this issue
            Watchers:
            102 Start watching this issue

              Created:
              Updated:
              Resolved: