Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectNodeProperty.java
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectGlobalPasswordRetriever.java
http://jenkins-ci.org/commit/envinject-plugin/95428b2fb1a750c2a1d3e7898f14c3d95b77e481
Log:
Fix JENKINS-16316

still failing

Can't reproduce

Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectComputerListener.java
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectEnvVars.java
http://jenkins-ci.org/commit/envinject-plugin/9e27cf40040a15cf67c1fc64bab90d28f2bc43e4
Log:
Fix reopen JENKINS-16316

–
You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

I've encountered this to still be an issue in specific cases on slave node execution (maybe some of this behaviour is intended?):

how to reproduce:

• hpi:run on current head with jenkins-version set to "1.480.3" (current LTS verison)
• configure a global property on master K/V: TESTVAR/value1
• configure a slave and start it
• configure a job restricted to run on that slave and to echo $TESTVAR.
• run the job (it will echo "value1")
• configure the global property on master to be: TESTVAR/value2
• dont restart anything
• rerun the job (it will still echo "value1")

however a job on master will recognize the changed value.

there are 2 pieces of code that lead to this behaviour. I'm pretty uncertain about the fix i made, but it resolves at least our problem with the plugin as i described it above, although i'm pretty sure it breaks some other intended feature.

https://github.com/kazesberger/envinject-plugin.git
https://github.com/kazesberger/envinject-plugin/commits/master

maybe someone can have a look at it and/or tell me what's the story behind this (Core)EnvironmentContributor thing.

i updated my pull request 12 days ago - providing:

• tests to reproduce/cover the issue/fix
• a better fix (my first attempt was as "wrong" as the original version)

i hope this gets reviewed/pulled.

What is the status of this issue? I'm not sure what version of EnvInject that this problem was introduced but it very cumbersome that these values are not dynamic. I also noticed that when clicking "System Information" for each slave that these global variables are registered in this list and this does not occur if the EnvInject plugin is not installed.

Could this in any way be related to change in JENKINS-16380 ?

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