Consider the following use case:

• Jenkins is installed in a folder on the main OS drive, C:\some_folder
• A secondary, larger "data" drive exists on the system, D:, and we want to set that to be the primary location for our job / build / workspace folders (e.g.: d:\builds)
• Further, since we have a non-trivial build configuration we need to configure several jobs in such a way that they share the same root working folder, with subsets of the projects stored in subfolders (e.g.: modules).

Now, intuitively one might think that the best way to manage this configuration would be to set up each related job with the same root folder via the "custom workspace folder" (as found under the advanced job configuration section). Also, to avoid having duplicated absolute paths in each job configuration one might think it intuitive to use relative paths for this property, expecting that the relative path would be relative to the custom root workspace folder setup earlier.

However, for some reason, when one enters a relative path in this custom workspace folder field, it is expected to be relative to JENKINS_HOME. I find this extremely non-intuitive to say the least. This behavior is also inconsistent with the interpretation of the "local module folder" setting in the SVN plugin (which is a path relative to the workspace) and the shell script build actions, which also assume that the working folder is the workspace folder and any relative paths used in the scripts are relative to the workspace.

As such I would highly recommend updating Jenkins such that relative paths entered in the "custom workspace" field in a job be changed so they are relative to the root workspace folder instead of relative to the Jenkins home folder.