jbochenski yes, the test coverage in the test suite is pretty bad. Any new tests would be appreciated, because there is no other way to standartize the plugin's resolution logic (env management is a mess in Jenkins).

Regarding the issue itself, likely I will be somehow reverting the behavior and making new logic optional. TBD.

oleg_nenashev it would be helpful if you could tell me which of the commits introduce the change as there are quite a few and I'm not sure if it's the plugin, the lib or both

https://github.com/jenkinsci/envinject-plugin/compare/envinject-2.1.3...envinject-2.1.4
https://github.com/jenkinsci/envinject-lib/compare/envinject-lib-1.26...envinject-lib-1.27

jbochenski it was https://github.com/jenkinsci/envinject-plugin/pull/125 for sure. See the changes in EnvInjectPluginAction#buildEnvVars(). This thing used to override all variables at some point, now it seems to not override some bits when it is really expected.

You can gather logs from the "org.jenkinsci.plugins.envinject.EnvInjectPluginAction" Logger on the CONFIG level to confirm it.

Created warning on Wiki: https://wiki.jenkins.io/display/JENKINS/EnvInject+Plugin 

Probably I should depublish the release for now

Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/envinject-plugin/956436e4825b87f1a18d7a842be03873f669f6c6
Log:
Add compatibility notice for JENKINS-47364 and JENKINS-47370

Code changed in jenkins
User: Oleg Nenashev
Path:
pom.xml
http://jenkins-ci.org/commit/envinject-plugin/05fffd291109514321bfbeab0fd62454ebb74f88
Log:
Merge pull request #127 from oleg-nenashev/2.1.4-compat-notice

Add compatibility notice for JENKINS-47364 and JENKINS-47370

Compare: https://github.com/jenkinsci/envinject-plugin/compare/03a66052daa3...05fffd291109

Hi!

We have a similar issue with parametrized builds; I.e. Job A triggers B and passes the parameter 'X=${X1}', but this variable X1 is unknown/not set. Job B receives (also for the previous release) 'X=${X1}' and has a envinject-step 'X1=${X}'. Up to EnvInject 2.1.3, the result of the variable substitution of X1 was an empty content (and this variable X1 was used in the batch-steps afterwards).

Beginning with EnvInject 2.1.4 the passed literal content (${X1}) is passed from the job-paramter X to the "local" variable X1 of the triggered Job B.  After some tests, we have found a work-around for this case:

• Add 'Prepare an environment for the run' in the job-configuration, but without any variable assignment
• Set option 'Override Build Parameters'

With this this option, the result of the substitution of X1 is an empty string/content like in the previous release. I have not made further tests, whether this work-around does solve only this (our) kind of variable-substitution issue or whether there are other side-effects ...

Best regards from Salzburg,
Markus

If you are not going to touch this issue anymore this is serious problem here, as administrator It's impossible to communicate to the team the DO NOT UPDATE EnvInject I have to ban all jenkins domains in the host Linux configuration level to stop Jenkins updates

My suggestion (only if you are not going to improve this fix causing regressions)

• branch the 2.1.3 version to a newer plugin called "Environment Injector Plugin (Old compatibility version)"

So we can stick to this version, because I believe we need Jenkins updates while we dont need EnvInject updates anymore and want it as it is working actually, the fix you published for it was not affecting us.

Unfortunately I will not have time to work on EnvInject issues for a while. I decided to unassign all issues so that somebody can take them and finalize.

Context: The plugin has been waiting for adoption for ~2 years. During all this time I was trying to keep this plugin afloat by reviewing the incoming pull requests, fixing defects and keeping the codebase up to date to simplify the handover. But I have not been using this plugin on my own so that such maintenance was a bit lame. I invite all active users to contribute to the plugin by taking ownership of this plugin and of EnvInject API. I am happy to provide any required knowledge transfers and do some assistance during the first months of maintenance

This seems to be fixed in 2.1.6