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

Folders should offer to use a hash for workspace path (like matrix does)

      When jobs are organized with lots of nested folders, the resulting workspace path can be long and will hit the windows 255 character max length (yes, we are in XXIth century and still suffer such issues)

      Matrix job offer an option to use a hash for workspace path as a workaround, folder could offer a comparable solution.

          [JENKINS-25330] Folders should offer to use a hash for workspace path (like matrix does)

          Daniel Beck added a comment -

          This is an issue tracker, not a support website. Please ask your questions in #jenkins on Freenode, or the jenkinsci-users mailing list.

          Daniel Beck added a comment - This is an issue tracker, not a support website. Please ask your questions in #jenkins on Freenode, or the jenkinsci-users mailing list.

          Jesse Glick added a comment -

          Not sure why this is filed in this plugin. Sounds like a core RFE to offer an alternate option for computing workspace path.

          Jesse Glick added a comment - Not sure why this is filed in this plugin. Sounds like a core RFE to offer an alternate option for computing workspace path.

          Daniel Beck added a comment -

          Didn't olivergondza publish a plugin that does this anyway?

          Daniel Beck added a comment - Didn't olivergondza publish a plugin that does this anyway?

          Yes, https://wiki.jenkins-ci.org/display/JENKINS/Short+Workspace+Path+Plugin.

          Though, I thing mirroring the folder/matrix hierarchy in workspace paths is a wrong approach and would like to see it fixed in core for all kinds of builds.

          Oliver Gondža added a comment - Yes, https://wiki.jenkins-ci.org/display/JENKINS/Short+Workspace+Path+Plugin . Though, I thing mirroring the folder/matrix hierarchy in workspace paths is a wrong approach and would like to see it fixed in core for all kinds of builds.

          Daniel Beck added a comment -

          mirroring the folder/matrix hierarchy in workspace paths is a wrong approach and would like to see it fixed in core for all kinds of builds.

          olivergondza In other words, make it impossible to find the workspace corresponding to a job on disk? Or WDYM?

          Daniel Beck added a comment - mirroring the folder/matrix hierarchy in workspace paths is a wrong approach and would like to see it fixed in core for all kinds of builds. olivergondza In other words, make it impossible to find the workspace corresponding to a job on disk? Or WDYM?

          Oliver Gondža added a comment - - edited

          Well, provided you can have can have a arbitrary deep hierarchy of Jenkins folders (and as the hierarchy is more or less mirrored in FS on both slave and master), we are just waiting for troubles when paths get too long. We hit this problem on windows slaves mostly but I had users complaining about matrix axis value generating FS path long enough for linux FS on Master.

          To me it seems that synthetically generated workspace paths (JENKINS_HOME) paths would solve most of that.

          Oliver Gondža added a comment - - edited Well, provided you can have can have a arbitrary deep hierarchy of Jenkins folders (and as the hierarchy is more or less mirrored in FS on both slave and master), we are just waiting for troubles when paths get too long. We hit this problem on windows slaves mostly but I had users complaining about matrix axis value generating FS path long enough for linux FS on Master. To me it seems that synthetically generated workspace paths (JENKINS_HOME) paths would solve most of that.

          Daniel Beck added a comment -

          All I'm saying is this should probably be opt-in. I heavily use disk based utilities to find out where all my free disk space went, and only having a bunch of UUIDs around would make it impossible to efficiently determine which job is what. Since folders are frequently used to group projects, retaining that hierarchy by default would also be useful.

          Of course this could just be a case of https://xkcd.com/1172/

          Daniel Beck added a comment - All I'm saying is this should probably be opt-in. I heavily use disk based utilities to find out where all my free disk space went, and only having a bunch of UUIDs around would make it impossible to efficiently determine which job is what. Since folders are frequently used to group projects, retaining that hierarchy by default would also be useful. Of course this could just be a case of https://xkcd.com/1172/ …

          Sorin Sbarnea added a comment -

          danielbeck, I think that https://issues.jenkins-ci.org/browse/JENKINS-30148 describes the problem better because is not limited to the "folder" plugin. At Red Hat we are hit by this issue seriously even without using folders.

          We need a generic solution that would work preferably for all job types. I added some comments on that ticket and I think we need some help from the core team for dealing with this 10+ years old issue.

          I think the generated names would work well in combination with transforming current workspace names to symlinks to the short ones.

          Sorin Sbarnea added a comment - danielbeck , I think that https://issues.jenkins-ci.org/browse/JENKINS-30148  describes the problem better because is not limited to the "folder" plugin. At Red Hat we are hit by this issue seriously even without using folders. We need a generic solution that would work preferably for all job types. I added some comments on that ticket and I think we need some help from the core team for dealing with this 10+ years old issue. I think the generated names would work well in combination with transforming current workspace names to symlinks to the short ones.

          Jesse Glick added a comment -

          only having a bunch of UUIDs around would make it impossible to efficiently determine which job is what

          That is why for branch projects we create workspace names which encode as much of the job name as possible, followed by a hash.

          Jesse Glick added a comment - only having a bunch of UUIDs around would make it impossible to efficiently determine which job is what That is why for branch projects we create workspace names which encode as much of the job name as possible, followed by a hash.

          Jesse Glick added a comment -

          I agree that this is a more general issue and should never have been filed in this plugin.

          Jesse Glick added a comment - I agree that this is a more general issue and should never have been filed in this plugin.

            danielbeck Daniel Beck
            fbelzunc Félix Belzunce Arcos
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: