I don't understand how "this is intentional" is a justification for this unexpected and very problematic behavior. Unfortunately, I'm not able to find any explanation in the release notes either.

Our project can't even be cloned because of this, making it impossible to use pipeline builds. And even if it wasn't problematic because of the path length:

"As builds tend to be disk I/O intensive, changing this value enables you to put build workspaces on faster storage hardware, such as SSDs or even RAM disks."

We don't get this with pipeline builds?

Use an agent and set the master to have zero executors.

This continues to be an issue - "use an agent" isn't an appropriate solution for setups where you only have 1 jenkins installation. Moreover, if the jenkins config has an option to set a workspace to a particular location than that location should be respected even on the master. The default location that Jenkins installs to on linux (redhat/centos at least) is /var/lib/jenkins. The /var partition is usually not very large!

At the very least if you aren't going to do anything else, that config setting should be updated with a help note indicating that multibranch pipeline execution will ignore the setting. I would endorse though that if a single node is being used for jenkins and the master is both checking the pipeline and executing the builds that the location from the system config is respected.

Dupe.

"Use an agent" isn't an appropriate response for jobs that must be run on the master. For example, a backup job that backs up the master. For example, a monitoring job that checks for some problem on the master–configuration change, out of disk space, etc. For example, a build job that uses a plugin with a bug where it won't run on the agent.

Once you allow these types of jobs to run on the master, some user can configure their build to run there for a while before you notice and make them move it. (This, of course, turns into disk space that would never be reused once you get them running on the agent.)

Plus multibranch pipeline jobs use a workspace when there are shared libraries to load from SCM and some other situations.

It works really well to move these jobs to a location on a different volume of the file system (as explained above)

Finally, if there is no reason to move the workspace for multibranch pipeline jobs, there is also no reason to move other job types. All the considerations are the same except the multibranch pipeline jobs create more workspaces because there can be one for every branch. The other types of jobs don't create and discard workspaces as the branches are created and discarded.

I completely agree with zswanson on:

Moreover, if the jenkins config has an option to set a workspace to a particular location than that location should be respected even on the master.

The plugin should respect global Jenkins settings and use its values.

And jglick I was trying to avoid going onto personalities, but as one of the lead developers of this plugin, please stop marking this issues as RESOLVED or DUPLICATE and find some time to understand why it is not working for everyone (I think previous posters explained it in details already).

Because currently all the communications can be shortly described as: "We decided it to be this way. Accept it or get lost."

From the description it appears to be a duplicate of the known issue which was recently fixed, so you just need to update your plugins.

jglick oh, I see. I found this original issue and PR on it (which this defect duplicates). I will try to update my plugins. Thanks.

Quick question.. We are using Jenkins 2.121.3 (& planning to upgrade to 2.164.3). Can I use custom workspace in Multibranch/Script pipeline !? 

Just use the dir or ws steps as needed.