-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
Jenkins 1.463, EnvInject 1.54 or 1.50
This looks like an exact regression to JENKINS-13183.
We have a Promotion job that injects an env var whose value contains references to other env vars, read from a properties file:
<buildSteps> <EnvInjectBuilder> <info> <propertiesFilePath>StageCraft.properties</propertiesFilePath> <propertiesContent>ReleaseDir=${ReleaseRoot}\${PROJECT_NAME}\${PROJECT_NAME}_${PROJECT_SHORT_VERSION} ReleaseDirTest=${env['PROJECT_SHORT_VERSION']} </propertiesContent> </info> </EnvInjectBuilder>
(note we added a 'ReleaseDirTest' env var to also try the alternate env var reference syntax).
EnvInject used to be fine with this, but after we did a few upgrades (to Jenkins itself and to the EnvInject plugin), it stopped working. Here's the output, together with a dump of the env vars injected in the build steps for diagnostics purposes:
Promoting ANONYMIZED #6 [EnvInject] - Injecting environment variables from a build step. [EnvInject] - Injecting as environment variables the properties file path 'StageCraft.properties' [EnvInject] - Variables injected successfully. [EnvInject] - Injecting as environment variables the properties content ReleaseDir=${ReleaseRoot}\${PROJECT_NAME}\${PROJECT_NAME}_${PROJECT_SHORT_VERSION} ReleaseDirTest=${env['PROJECT_SHORT_VERSION']} [EnvInject] - Variables injected successfully. [EnvInject] - Unset unresolved 'ReleaseDir' variable. [EnvInject] - Unset unresolved 'ReleaseDirTest' variable. build org.jenkinsci.plugins.envinject.EnvInjectBuilder@53c01def SUCCESS [workspace] $ cmd /c call C:\Users\svc_ci\AppData\Local\Temp\hudson1186946183352599382.bat C:\jenkins\jobs\ANONYMIZED\workspace>SET ALLUSERSPROFILE=C:\ProgramData ... ProgramW6432=C:\Program Files PROJECT_FULL_VERSION=1.6.0.7 PROJECT_NAME=ANONYMIZED PROJECT_SHORT_VERSION=1.6.0 PROMOTED_ID=2012-06-01_15-42-27 ... C:\jenkins\jobs\Cupid_1.6.x\workspace>exit 0
[JENKINS-14006] EnvInject stopped resolving environment variables in environment variables
Gregory Boissinot
added a comment - I don't have sufficient information to reproduce the issue.
Could you give me more information such as which promotion plugin do you use?
Thanks
Gregory Boissinot
added a comment - I don't have sufficient information to reproduce the issue.
Could you give me more information such as which promotion plugin do you use?
Thanks 
Gabriele Giuseppini
added a comment - Attached the whole list of plugins and their versions.
Thank you for looking into this. Let me know if I can be of further help.
Gabriele Giuseppini
added a comment - Attached the whole list of plugins and their versions.
Thank you for looking into this. Let me know if I can be of further help. Gregory Boissinot
added a comment - I can't reproduce due to the complex workflow.
If you are able to isolate the problem and to provide a dedicated zip, it will be fine.
Thanks
Gregory Boissinot
added a comment - I can't reproduce due to the complex workflow.
If you are able to isolate the problem and to provide a dedicated zip, it will be fine.
Thanks 
Darragh Bailey
added a comment - This showed up for me with 1.53 and using the build step for environment injection.
If for a node, you configure the environment (http://localhost:8080/configure Global Properties) by adding a key-value pair such as
PATH => $PATH:/my/custom/tools/path
MY_PROP => Hello World
The modified PATH property will not be set for any build steps executed after a "inject environment properties" step, instead you'll just get the system default that the build slave was started with. However setting properties directly such as MY_PROP continue to work as expected.
To test:
jenkins 1.471
Only additional plugin = EnvInject plugin 1.53
A simple job with build steps (linux)
<shell>
set
echo "HELLO = world" > envionment.properties
</shell>
<Inject environment variables>
Properties file path => envionment.properties
</Inject environment variables
<shell>
set
</shell>
When you run the job, in the console the properties list for the first build step will show the PATH being modified, while after the injection step, you will see the unmodified path.
With an upgrade Environment Injector Plugin v1.55 to the problem occurs for the first build step as well.
Darragh Bailey
added a comment - This showed up for me with 1.53 and using the build step for environment injection.
If for a node, you configure the environment ( http://localhost:8080/configure Global Properties) by adding a key-value pair such as
PATH => $PATH:/my/custom/tools/path
MY_PROP => Hello World
The modified PATH property will not be set for any build steps executed after a "inject environment properties" step, instead you'll just get the system default that the build slave was started with. However setting properties directly such as MY_PROP continue to work as expected.
To test:
jenkins 1.471
Only additional plugin = EnvInject plugin 1.53
A simple job with build steps (linux)
<shell>
set
echo "HELLO = world" > envionment.properties
</shell>
<Inject environment variables>
Properties file path => envionment.properties
</Inject environment variables
<shell>
set
</shell>
When you run the job, in the console the properties list for the first build step will show the PATH being modified, while after the injection step, you will see the unmodified path.
With an upgrade Environment Injector Plugin v1.55 to the problem occurs for the first build step as well. Darragh Bailey
added a comment - basic jenkins config Darragh Bailey
added a comment - simple job exhibiting the problem Gregory Boissinot
added a comment - @Darragh Bailey
It seems it is another issue. Anyway it should be fixed in 1.56.
If not, could you open another bug.
Gregory Boissinot
added a comment - @Darragh Bailey
It seems it is another issue. Anyway it should be fixed in 1.56.
If not, could you open another bug. Darragh Bailey
added a comment - Nope not fixed, but slightly different output.
Did seem too similar not to be the same underlying issue, but will log a new one as requested with the new output.
Darragh Bailey
added a comment - Nope not fixed, but slightly different output.
Did seem too similar not to be the same underlying issue, but will log a new one as requested with the new output. Gabriele Giuseppini
added a comment - Yes, it appears it has disappeared after some latest upgrades.
Gabriele Giuseppini
added a comment - Yes, it appears it has disappeared after some latest upgrades. 
Attaching the anonymized job config. Unfortunately, the rest of the folder contains a lot of sensitive information. I will provide specific files on demand if really needed.