Seems unrelated to folders and should be a core feature (maybe via extension point) instead. While folders often lead to long fullNames, it's not the only way to have that problem.

This issue is now sponsored to be fixed
https://freedomsponsors.org/issue/580/folders-should-offer-to-use-a-hash-for-workspace-path-like-matrix-does

(obsolete comment; found the acceptance criteria)

Nicolas: Please let me know if you were planning to work on this.

arazasplunk:

Here's a build of a plugin that adds this feature to the configuration of folders (needs Folders 4.6.1, Jenkins 1.565.3; but that can be changed):
https://dl.dropboxusercontent.com/u/29853/short-workspace-20141031.hpi

• Allows enabling option per folder on the folder's config screen ("Use short workspace paths")
  • has additional option "Place short workspace inside the workspace of this folder" to place workspace directory with short name inside folder's workspace, to still have some organization
• Works for freestyle projects, matrix projects, and build flows (and everything else with regular workspace implementation)
• Uses JENKINS_HOME/workspace/... on master, configured slave workspace directory (hudson.model.Slave.workspaceRoot) on slaves
• Tested with Windows slaves, works like a charm (except Subversion checkout in Build Flow didn't work for some reason – build.workspace.child("foo").write("bar", "UTF-8") in the DSL however did).

Diagnostic information is logged to org.jenkinsci.plugins.shortworkspace.ShortWorkspaceLocator.

Configure the name of the top-level workspace folder on the Jenkins master node (default: "workspace") by setting the system property org.jenkinsci.plugins.shortworkspace.ShortWorkspaceLocator.defaultWorkspaceFolder. Example: java -Dorg.jenkinsci.plugins.shortworkspace.ShortWorkspaceLocator.defaultWorkspaceFolder=ws -jar jenkins.war

The following requirements were possibly not followed to the letter; clarification would be appreciated:

• "No forking, release required" – I opted for a new plugin (that will be published to github.com/jenkinsci and released to Update Center).
• "As long as it can be applied globally" – It's configurable per folder; let me know if you need a fully global option
• "must apply to both freestyle job type and buildflow job type" – This plugin applied to all regular job types

Let me know what you think.

Hi Daniel,
Thanks for the quick turn around. Let me test this out and get back to you.

Daniel,
Can this be part of the folder plugin rather than a separate plugin?

arazasplunk:
From a technical POV, yes. The package names for logging and the option name would change, that's it. Note that there is no functional or other advantage for you other than this feature being included without installing another plugin; for example the addition to the folder config form uses the same API as e.g. the similar Credentials-related options. In fact, functionally it'd be better left separate, as it'd allow users on older Jenkins + Folders versions to use it as well once I reduce the version requirements.

Whether the addition would be accepted by the Folders maintainers is another question. Since this proposal was filed by CloudBees employees I'm hopeful, but whether the specific implementation is acceptable, I don't know. If changes are requested by them, you'd have to evaluate which you prefer.

Do you have any other comments/requests regarding this plugin? Is the functionality as expected? Are the parts in which I differed from the acceptance criteria acceptable? (What's still missing is the inline help for the two options, that's still on the todo list.)

Hi Daniel,
I didn't get much of a chance to test today. Will this weekend. A few questions
1. I have folder > subfolder 1 -> subfolder 2> etc. Should this option be checked in all the folders for the desired effect?
2. Can you add some screenshot of what the results look like before and after this setting.

Thanks

1. I have folder > subfolder 1 -> subfolder 2> etc. Should this option be checked in all the folders for the desired effect?

It is enabled for a job when any folder in it's hierarchy has this enabled. So if FoldA/FoldB has the property set, it will be effective for FoldA/FoldB/job1 and FoldA/FoldB/FoldC/job2, but not for FoldA/job3 or job4. For the 'advanced' option to place the workspace inside the folder's workspace, it uses the configuration of the innermost/most deeply nested folder that has 'Use short workspace enabled'.

Example:

FoldA - no short workspace selected
FoldA/FoldB - short workspace selected
FoldA/FoldB/FoldC - short workspace selected, and opting in to place it inside folder's workspace
FoldA/FoldB/FoldC/FoldD - no short workspace selected
FoldA/FoldB/FoldC/FoldD/FoldE - short workspace selected

Then the following behavior will occur:

FoldA/job1 - Workspace is JENKINS_HOME/workspace/FoldA/job1 (no element in the hierarchy has the option enabled)
FoldA/FoldB/job2 - Workspace is JENKINS_HOME/workspace/01234abcd (enabled through parent folder, but not placed inside the parent folder's workspace)
FoldA/FoldB/FoldC/job3 - Workspace is JENKINS_HOME/workspace/FoldA/FoldB/FoldC/abcd01234 (enabled through parent folder, and placed inside parent folder's workspace)
FoldA/FoldB/FoldC/FoldD/job4 - Workspace is JENKINS_HOME/workspace/FoldA/FoldB/FoldC/4321dcba (enabled through grandparent folder, and placed inside grandparent folder's workspace)
FoldA/FoldB/FoldC/FoldD/FoldE/job5 - Workspace is JENKINS_HOME/workspace/9876cafe (enabled through parent folder, and no placed inside parent folder's workspace)

2. Can you add some screenshot of what the results look like before and after this setting.

I'm not sure what you want to see. Windows Explorer? The build log mentions where the workspace is (for freestyle jobs at least, didn't try for Build Flow, and it looks like

Building on master in workspace /var/lib/jenkins/workspace/c032452b

Building on master in workspace /var/lib/jenkins/workspace/FoldA/FoldB/c032452b

Building on master in workspace /var/lib/jenkins/workspace/FoldA/FoldB/job2

Results are similar on Windows, just e.g. C:\Jenkins rather than /var/lib/jenkins.

arazasplunk: Any news?

HI how to resolve the following issue ?

"The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."

i installed short workspace plugin. i don't know how to configure the path. or please suggest any other way to resolve the issue.

and how to change hash workspace?
please do need helpful.

Thanks,
Dhananjaya

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

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.

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?

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.

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/ …

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.

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.

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