The following workaround fixed it for me:

On main jenkins config page, turn on the option "Prepare jobs environment" and unselect "Unset System Environment Variables"
Save Config and restart the slave.

I think it is related to the following code in EnvironmentVariablesNodeLoader:

for (NodeProperty<?> nodeProperty : Hudson.getInstance().getGlobalNodeProperties()) {
    if (nodeProperty instanceof EnvironmentVariablesNodeProperty) {
        EnvironmentVariablesNodeProperty variablesNodeProperty = (EnvironmentVariablesNodeProperty) nodeProperty;
        EnvVars envVars = variablesNodeProperty.getEnvVars();
        EnvInjectEnvVars envInjectEnvVars = new EnvInjectEnvVars(logger);
        configNodeEnvVars.putAll(envVars);
        envInjectEnvVars.resolveVars(configNodeEnvVars, nodeEnvVars);
    }
}

Without the "Prepare jobs environment" checked, the if statement above resolves to false so env vars are not updated.... i think.

That workaround doesn't seem to work for me however.

I filed a new pull request to fix this.

Upgrading priority since this bug breaks basic Jenkins functionality merely by installing a plugin, so it is far from obvious to a user where to start diagnosis.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java
http://jenkins-ci.org/commit/envinject-plugin/dedee1978345fa23e7d3773f64572c4a6f027882
Log:
[FIXED JENKINS-16316] Do not inject master node property variables into EnvVars.masterEnvVars on slaves.

Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java
http://jenkins-ci.org/commit/envinject-plugin/3371ed7601431b57780a30ddea4b84dd27e38b6e
Log:
Merge pull request #20 from jglick/sticky-var-JENKINS-16316

JENKINS-16316 Changes to global variables not honored.

Compare: https://github.com/jenkinsci/envinject-plugin/compare/b5cc29fc9695...3371ed760143

Upgrading to 1.88 has fixed the problem for me as well.

Not sure if it is the same bug or a new one:
When you have a build parameter, and you try to inject a value to it, the value is not injected.

Ways to reproduce:
JOB #1
----------
1. Add build parameter called BRANCH (or whatever name you like)
2. Add shell script with echo "BRANCH=test" > build.prop
3. Inject build.prop using the envinject plugin
4. echo ${BRANCH}
>> this echos blank value (or the default value set to parameter) instead of "test"

JOB #2
-----------
1. remove the parameter named BRANCH.
Rest of the steps (2-4) remain the same:
2. Add shell script with echo "BRANCH=test" > build.prop
3. Inject build.prop using the envinject plugin
4. echo ${BRANCH}
>> this echos "test"

We've upgraded Jenkins to 1.584 and envinject plugin to 1.90 and this behavior happens.

Job #1 and Job #2 should both echo "test" to the screen.

This was working before the upgrade we did (I don't remember which plugin version we had previously).

Thanks.

guyshaanan:

Not sure if it is the same bug or a new one

Then file a new bug report, and link it to this one as possibly related.

Issue still occuring on 1.92.1

Had to revert to 1.88 to get it working

Seems like there is a toss up between ->
1. people using it on master (like me to inject variables during a build)
2. people using it on nodes to set up the environment at the beginning.

When one feature works the other seems to fail

for usage 1 -> 1.88 works perfectly
for usage 2 -> 1.92.1 seems to work

Maybe fork the plugin into two separate plugins