Minor It seems that accessing parameters with build command 'Execute shell' has strange syntax when building with URL request and multiple parameters.
For example, when I trigger my build with URL:
http://server/job/myjob/buildWithParameters?token=TOKEN&PARA1=Value1&PARA2=Value2
and try to echo those string parameters, I need to use the following syntax:
echo $PARA1
echo ${para2}
For example this alternative doesn't work. It is echoing only blank values:
echo ${para1}
echo $PARA2
This seems to be somewhat similar to this:
https://issues.jenkins-ci.org/browse/JENKINS-16639
[JENKINS-25020] Accessing parameters of triggered build has strange syntax
Kaaleppi Kekkola
added a comment - Correct.
Outputs something:
echo $para2
Outputs nothing:
echo $para1
echo $para2
Kaaleppi Kekkola
added a comment - Correct.
Outputs something:
echo $para2
Outputs nothing:
echo $para1
echo $para2 And just to be sure: a new freestyle project (no parameters or anything) building on the same slave that only runs env in a shell build step will include para2 among the variables printed as well?
No it won't include para2. The parameters I'm talking about in the description are those declared in "This build is parameterized" part.
Kaaleppi Kekkola
added a comment - - edited No it won't include para2. The parameters I'm talking about in the description are those declared in "This build is parameterized" part. Could you please provide specific parameter/variable names?
My assumption so far was that 'para2' was defined somewhere else (e.g. global Jenkins configuration, node configuration, ...), and Jenkins' case insensitive behavior then overrode the original value using the parameter PARA2. Since you're saying that without the parameter PARA2 being defined in the job, para2 is not actually set, I don't understand what's going on.
Kaaleppi Kekkola
added a comment - Sorry for being confusing.
I was actually using Jenkins build parameter named 'user' and I just realized that I also have an environment variable which is named equally. I thought I was experiencing the problem with different parameter names as well but apparently that wasn't the case when testing now.
"This seems to be a known issue affecting variables that have already been defined" seems to be the case really. Thanks for the help.
Kaaleppi Kekkola
added a comment - Sorry for being confusing.
I was actually using Jenkins build parameter named 'user' and I just realized that I also have an environment variable which is named equally. I thought I was experiencing the problem with different parameter names as well but apparently that wasn't the case when testing now.
"This seems to be a known issue affecting variables that have already been defined" seems to be the case really. Thanks for the help.
This seems to be a known issue affecting variables that have already been defined, as Jenkins treats them case-insensitive but case-preserving.
If you remove the PARA2 parameter and `echo $para2`, it will output something, correct?