-
Bug
-
Resolution: Duplicate
-
Trivial
-
None
This is probably more a miss usage than an issue. In that case, would you please add some precisions on the basic-steps documentation?
Description of the issue:
I have a simple pipeline with the string parameter "ENVNAME". A call to
def var = 'foo' withEnv(["envname=${var}"]) { sh 'echo $envname' }
results in an empty string even with the parameter variable ENVNAME defined (but I am not looking for this variable here) I would have not expected variable name clash here. Would you?
Moreover, the implementation is under a jenkins library, there is no clever way to avoid collision (but to check env.ENVNAME before) that comes to my mind.
Of course, changing the string "envname" to whatever else works as intended.
- is caused by
-
-
- Resolved
-
[JENKINS-46379] withEnv mess with Job parameter (not case sensitive)
Kevin Raymond
added a comment - 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?
Kevin Raymond
added a comment - 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? Kevin Raymond
added a comment - 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
Kevin Raymond
added a comment - 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?
Kevin Raymond
added a comment - Coding a pipeline with environment variable (either job parameter defined or global jenkins configuration) and sh step is just a matter of try'n fix...
I just avoid them as much as possible 
Kevin Raymond
added a comment - Coding a pipeline with environment variable (either job parameter defined or global jenkins configuration) and sh step is just a matter of try'n fix...
I just avoid them as much as possible I also met this issue. Do we have any plan to fix this issue in future release?
James Green
added a comment - 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
{ string(name: "DockerHost", defaultValue: "tcp://0.0.0.0:2376", description: "Private IP of a swarm manager to which you want to deploy.") string(name: "WhichProvider", defaultValue: "aws", description: "Who is providing the infrastructure? 'aws' or 'regular' are possible values.") }...
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.
James Green
added a comment - 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
{
string(name: "DockerHost", defaultValue: "tcp://0.0.0.0:2376", description: "Private IP of a swarm manager to which you want to deploy.")
string(name: "WhichProvider", defaultValue: "aws", description: "Who is providing the infrastructure? 'aws' or 'regular' are possible values.")
}
...
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.
Tim Lynch
added a comment - bump I just banged my head against this:
withenv(["FOOBAR=${params.fooBar}"]) { sh 'printenv |grep -i foobar' }
Tim Lynch
added a comment - bump I just banged my head against this:
withenv([ "FOOBAR=${params.fooBar}" ]) {
sh 'printenv |grep -i foobar'
}
Can you give your plugin versioin? Because it'is all right. My plugin version like bleow:
Pipeline: Basic Steps 2.6
shaiton