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

Give the ability to choose how the multibranch subprojects will be named.

      The %2F encoding of / breaks many software (msbuild for example) and can't be changed.
      Being able to provide a rule to build the subproject names from the branch name instead of just encoding things would permit to give the user the power to work around their problems with this kind of software.

      This would be an advanced option in which one can write something like a sed regex.

          [JENKINS-34564] Give the ability to choose how the multibranch subprojects will be named.

          Varun Reddy added a comment -

          I have completely removed and now the workspace folders names are large.

          I think that was the main reason I have added PATH_MAX=0. Now Is there a way I can avoid long path

          Varun Reddy added a comment - I have completely removed and now the workspace folders names are large. I think that was the main reason I have added PATH_MAX=0. Now Is there a way I can avoid long path

          Michael Neale added a comment -

          varun7447 if you set it to a value that is non zero - does it make it shorter without resorting to the URI encoding? 

          like set it to say 20 (it needs enough to make it not collide, as it will be a hash basically)

          Michael Neale added a comment - varun7447 if you set it to a value that is non zero - does it make it shorter without resorting to the URI encoding?  like set it to say 20 (it needs enough to make it not collide, as it will be a hash basically)

          Varun Reddy added a comment -

          michaelneale Yeah I tried different combinations. The encoding seems to be fixed. But the problem is the workspace names are messed up. If I have to troubleshoot anything it is hard by looking at the workspace name, if the workspace belongs to which job.

          Varun Reddy added a comment - michaelneale Yeah I tried different combinations. The encoding seems to be fixed. But the problem is the workspace names are messed up. If I have to troubleshoot anything it is hard by looking at the workspace name, if the workspace belongs to which job.

          diewu qin added a comment -

          Anyone can tell me if this issue fixed? I use parameter " -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=20 " but did not work, and my jenkins version is 2.89.4.

          diewu qin added a comment - Anyone can tell me if this issue fixed? I use parameter " -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=20 " but did not work, and my jenkins version is 2.89.4.

          Nick Jones added a comment -

          Attempting to use '\\?\' as a path prefix – in my case, setting '\\?\C:\Jenkins' as the "Remote root directory" for my JNLP-connected Windows agent – resulted in a "java.nio.file.InvalidPathException: Illegal character [?] in path" exception being thrown, which similar to https://bugs.openjdk.java.net/browse/JDK-8165748 (although I'm using the Oracle JRE8). It would appear that my only options with Windows agents to reduce overall path length (until JENKINS-2111 is implemented) is the use of the '-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX' parameter, which given the merge of https://github.com/jenkinsci/branch-api-plugin/pull/62 would appear to support generated paths as short as 12 characters, far less than the 80 being generated by default.

          Nick Jones added a comment - Attempting to use '\\?\' as a path prefix – in my case, setting '\\?\C:\Jenkins' as the "Remote root directory" for my JNLP-connected Windows agent – resulted in a "java.nio.file.InvalidPathException: Illegal character [?] in path" exception being thrown, which similar to https://bugs.openjdk.java.net/browse/JDK-8165748 (although I'm using the Oracle JRE8). It would appear that my only options with Windows agents to reduce overall path length (until JENKINS-2111 is implemented) is the use of the '-Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX' parameter, which given the merge of https://github.com/jenkinsci/branch-api-plugin/pull/62 would appear to support generated paths as short as 12 characters, far less than the 80 being generated by default.

          Uma Shankar added a comment - - edited

          Hey guys, this seems to be still a problem with latest LTS Jenkins, I have Jenkins on Windows with a slave. I have used starting parameter as -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=2 works well on master, however builds on Node is still creating %2F folder which is breaking all the MSBuild projects

           

          Folder on Master:

           

          Folder on Slaves:

           

          Jenkins Version: Jenkins ver. 2.138.2

          Branch API version: 2.0.20

           

          Is there some specific configuration for slaves?

           

           

          Uma Shankar added a comment - - edited Hey guys, this seems to be still a problem with latest LTS Jenkins, I have Jenkins on Windows with a slave. I have used starting parameter as -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=2 works well on master, however builds on Node is still creating %2F folder which is breaking all the MSBuild projects   Folder on Master:   Folder on Slaves:   Jenkins Version:  Jenkins ver. 2.138.2 Branch API version: 2.0.20   Is there some specific configuration for slaves?    

          Jesse Glick added a comment -

          Please do not reopen. If you encounter bugs, file them separately with complete steps to reproduce from scratch. Or just try my proposed implementation of JENKINS-2111, which reduces path lengths considerably.

          Jesse Glick added a comment - Please do not reopen. If you encounter bugs, file them separately with complete steps to reproduce from scratch. Or just try my proposed implementation of JENKINS-2111 , which reduces path lengths considerably.

          Uma Shankar added a comment -

          jglick Apologies for reopening this issue. Regarding proposed implementation in JENKINS-2111, are you suggesting to use branch-api 2.0.21 ? What does it have different than 2.0.20, would like to know before putting it on production Jenkins instance?

           

          Also, JENKINS-2111 looks more about cleanup than fixing multi branch workspace folder name.

          Uma Shankar added a comment - jglick Apologies for reopening this issue. Regarding proposed implementation in JENKINS-2111 , are you suggesting to use branch-api 2.0.21 ? What does it have different than 2.0.20, would like to know before putting it on production Jenkins instance?   Also,  JENKINS-2111  looks more about cleanup than fixing multi branch workspace folder name.

          Jesse Glick added a comment -

          are you suggesting to use branch-api 2.0.21 ?

          When released. Or you can install a build from my PR today.

          What does it have different than 2.0.20

          A completely different system for selecting and managing workspace paths. Best discussed in the other issue or PR.

          Jesse Glick added a comment - are you suggesting to use branch-api 2.0.21 ? When released. Or you can install a build from my PR today. What does it have different than 2.0.20 A completely different system for selecting and managing workspace paths. Best discussed in the other issue or PR.

          Gerard added a comment - - edited

          I'm seeing this issue again (slashes coming up as "%2F" instead of "_") after my company upgraded from Jenkins 2.387.3 to 2.452.3 (and branch-api-plugin 2.1105 to 2.1178). Has anyone else seen it? It's causing lots of issues across many pipelines.

          Edit: It turns out a new plugin (ws-ws-replacement) was pulled in as a part of our upgrade. That plugin was also implementing WorkspaceLocator and beating the branch-api-plugin's implementation to the punch. It was only substituting spaces with underscores, hence leaving the "%2F" there and causing problems.

          Gerard added a comment - - edited I'm seeing this issue again (slashes coming up as "%2F" instead of "_") after my company upgraded from Jenkins 2.387.3 to 2.452.3 (and branch-api-plugin 2.1105 to 2.1178). Has anyone else seen it? It's causing lots of issues across many pipelines. Edit: It turns out a new plugin (ws-ws-replacement) was pulled in as a part of our upgrade. That plugin was also implementing WorkspaceLocator and beating the branch-api-plugin's implementation to the punch. It was only substituting spaces with underscores, hence leaving the "%2F" there and causing problems.

            jglick Jesse Glick
            rkutic Kevin Grandemange
            Votes:
            59 Vote for this issue
            Watchers:
            84 Start watching this issue

              Created:
              Updated:
              Resolved: