Just ran into this issue using withEnv in a docker container. Works for everything but PATH currently.

I believe this may be the root cause as well with the failures I'm seeing within a declarative pipeline. Running this PATH from the env command is the normal value and not the value within my pipeline. This only seems to break when the agent is a docker

pipeline {
    agent {
        docker {
            image 'debian:stretch'
        }
    }
    
    environment {
        PATH = "/opt/test/bin:/usr/bin/:/bin"
    }
    
    stages {
        stage('Example') {
            steps {
                sh 'env'
            }
        }
    }
}

I'm seeing same issue here.

It is definitely necessary to have a way to set PATH variable inside docker container. We have a PATH environment variable is dynamic changing with Jenkins workspace path that can only set through code.

Is there a workaround for this issue?

I did something like this as workaround:

    // Get the full PATH variable from a started container.
    def pathInContainer
    docker.image(DockerImage).inside() {
      pathInContainer = steps.sh(script: 'echo $PATH', returnStdout: true).trim()
      parameters += "-e PATH=${pathInContainer}:/misc/AddExtraPath "
    }    

    docker.image(DockerImage)
                .inside(parameters) {
      runA()
      runB()
    }
 

It extracts the PATH from a started container, then stops the container, and starts a new one with the extra PATH environment variable (which I extended with the things required by us).

Thank you theuno! Let me have a try

Any update on this issue? The workaround by theuno works, but its very ugly and inpractical for some use cases.

Another workaround is to run commands in a modified environment:

pipeline {
    agent {
        docker {
            image 'debian'
        }
    }
    environment {
        PATH = '/some/dir'
    }
    stages {
        stage('Test') {
            steps {
                sh "env PATH=$PATH:\$PATH"
            }
        }
    }
}

The resulting PATH variable contains /some/dir prepended to the PATH value defined inside the container (observe double quotes in the steps directive).

I fully agree with the others, that the option to manipulate the PATH variable inside a container is a must-have. Note, that this feature has nothing to do with setting the PATH inside a container to the value this variable has outside of it, i.e. on the Jenkins node, which would be obviously wrong in most cases.