If you are referring to multibranch Pipeline jobs (branch projects), this is intentional; see release notes for workflow-multibranch.

jglick I do understand that it will take some time for your to find a correct link, but referring to release note of workflow-multibranch plugin without any details does not help a lot. By reading latest changelog on the above named plugin I could not find any mention of workspace handling changes (changelog: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Multibranch+Plugin).

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.