I'm confused. Are you saying that "envname=whatever" doesn't take effect if ENVNAME is already defined?

Yes exactly.

Let's take a full example. I have a simple pipeline with only one string parameter "ENVNAME" which default value is "foo".

Here is the pipeline code:

stage('test'){
    def var = 'bar'

    node{
        echo env.ENVNAME
        //   foo

        withEnv(["envname=${var}"]) {
            sh 'echo "envname is: $envname while ENVNAME is: $ENVNAME"'
            //        envname is:  while ENVNAME is: bar
        }
        
        withEnv(["name=${var}"]) {
            sh 'echo "name is: $name while ENVNAME is: $ENVNAME"'
            //        name is: bar while ENVNAME is: foo
        }
    }
}

And the output is following:

[Pipeline] stage
[Pipeline] { (test)
[Pipeline] node
Running on localhost in /home/slave/j2data/workspace/dummy-pipeline
[Pipeline] {
[Pipeline] echo
foo
[Pipeline] withEnv
[Pipeline] {
[Pipeline] sh
[dummy-pipeline] Running shell script
+ echo 'envname is:  while ENVNAME is: bar'
envname is:  while ENVNAME is: bar
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] withEnv
[Pipeline] {
[Pipeline] sh
[dummy-pipeline] Running shell script
+ echo 'name is: bar while ENVNAME is: foo'
name is: bar while ENVNAME is: foo
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
Finished: SUCCESS

I would think the first withEnv block would print the variable. Either the redefined one or the job parameter. Instead, it just drops the value without being case sensitive.

Can you give your plugin versioin? Because it'is all right. My plugin version like bleow:
Pipeline: Basic Steps 2.6

shaiton

I am also using Basic Steps 2.6 under Jenkins ver. 2.73.3

I have just reproduced this issue. How can I give you more input?

You just use the case that your last post? I can retry it.
shaiton

yes surenpi the one I posted as a comment-311533.

Have you defined a String parameter spelled 'ENVNAME' in your pipeline?
I am adding the config.xml job definition. config.xml

This drove me utterly insane working on my pipeline until I figured out what was symptomatically going on and came across this bug. Is there anything I can do to help move forwards addressing this issue?

I also met this issue. Do we have any plan to fix this issue in future release?

This has just driven us utterly nuts and made us introduce bugs in our deployment scripts. Here's what you need to know:

Do not create an environment variable who's name matches (case insensitively) the parameter name!

Here's a Jenkinsfile that actually works:

parameters

...

withEnv(["DOCKER_HOST=${params.DockerHost}", "PROVIDER=${params.WhichProvider}"]) {

...

At this point DOCKER_HOST and PROVIDER have the correct values within the environment. The documentation should at least mention this. A warning should perhaps me issued when withEnv operates and finds an existing environment variable.

bump I just banged my head against this:

withenv(["FOOBAR=${params.fooBar}"]) {
  sh 'printenv |grep -i foobar'
} 

also will be documented in the inline help once the PR is merged.