When running a Jenkins setup with multiple servers, the $WORKSPACE variable inside agent { docker } inside stage points to the path on the server that started the build, not to the path on the server that's starting the container. 

Example: assuming we have Jenkins running on a node labeled "master" which stores workspaces in /var/lib/jenkins/workspaces/ and one "slave" connected which stores workspaces in /home/jenkins/workspaces/, this pipeline:

pipeline {
   agent {
      label 'master'
   }

   stages {
      stage('step 1'){
         steps{
            sh """
               printenv // $WORKSPACE=/var/lib/jenkins/workspaces/abc
            """
         }
      }
   stage('step 2') {
         agent {
            docker {
               image 'centos:centos7'
               args "-v $WORKSPACE:/var/www/" // $WORKSPACE=/var/lib/jenkins/workspaces/abc
               label 'slave'
            }
         }
         steps {
            sh """
               cd /var/www/
               printenv // $WORKSPACE=/home/jenkins/workspaces/abc
            """
         }      
          }
   }
}

$WORKSPACE used in args will point to the path on the "master", not on the "slave" which is really running the container.
$PWD points to jenkins home (/home/jenkins/ in the example), which is even less useful.
This gets even more complicated once we have multiple stages and the "@2" and so on get created.

In this problematic spot, WORKSPACE is set to the original workspace, and not to the real working directory. The value of the working directory is available at this point, since it's passed here: https://github.com/jenkinsci/docker-workflow-plugin/blob/master/src/main/java/org/jenkinsci/plugins/docker/workflow/client/DockerClient.java#L106 as "workdir". Is this available as another variable perhaps at this stage or is it not exposed at all?

Obviously, if we remove the labels, the job can still jump between nodes and create this specific problem. I'm attempting to work around this for now by using "reuseNode true", but that creates its own problems when we need to scale nodes and jobs queue up and we would actually want to take advantage of the stages being run on a different node that the original one.

Use case:

We use this specific setup, because inside that docker container we run "pip install" to prepare a virtual environment for deployment on multiple servers hosting our python app. This helps us avoid running "pip install" on every server during deploy... The set path (/var/www/) is needed, because pip hard-codes absolute paths to everything when it creates the venv and cannot be fooled by symlinks during build (as far as we could tell).