Strange behavior.
I don't know where it is from and I can't reproduce it.
Could you try to isolate it?
Are your sure?

Thanks. I am sure... I will try something on our test server and get back to you.

Did you have time to test it?
Thanks in advance.

Any update?

I'm closing the issue at the moment because I cannot reproduce it without more inputs.
Do not hesitate to reopen it when you will have more information.
Thanks in advance.

I'm seeing this same issue with Jenkins 1.454 & the EnvInject plugin 1.74-SNAPSHOT from yesterday. I had 1.72 when I initially encountered this. Not reopening the bug yet, because I have no further useful information.

The problem appears to get fixed by upgrading Jenkins core to 1.489.

Ok thanks Mikko for your last update.

The issue still exists. Jenkins 1.513, EnvInject 1.85

Same story as the original reporter: Downgrading EnvInject to 1.36 fixes it.

Strongly reproduced with scripttrigger plugin
jenkins core: 1.492
evinject: 1.82
scripttrigger: 0.26, 0.23

steps to reproduce:

• JOB1. create any job that polls using scripttrigger plugin with poling node = master
• JOB2. create job which is restricted to run on master and uses envinject
• (restart jenkins - looks like it is needed)
• run JOB2

The results is that $WORKSPACE of JOB2 is defined correctly before envinject, but then it is re-defined with $WORKSPACE of job which use scripttrigger (JOB1).

==========
Started by user ...
[EnvInject] - Loading node environment variables.
Building on master in workspace /jenkins/jobs/JOB2/workspace
[EnvInject] - Executing scripts and injecting environment variables after the SCM step.
[EnvInject] - Executing and processing the following script content:
A=aaaa

[workspace] $ /bin/sh -xe /tmp/hudson5302730654246338218.sh
+ A=aaaa
[EnvInject] - Script executed successfully.
[workspace] $ /bin/sh -xe /tmp/hudson6529723899012472418.sh
+ echo /jenkins/jobs/JOB1/workspace
/jenkins/jobs/JOB1/workspace
Notifying upstream projects of job completion
Finished: SUCCESS
===========

Can it be related that envinject and scripttrigger use different envinject-lib ?
envinject uses envinject-lib-1.15.jar while scripttrigger uses envinject-lib-1.16.jar ?

I can reproduce the issue using Natalia's steps, but not consistently. To check if WORKSPACE has been modified you can check the value of hudson.EnvVars.masterEnvVars using the script console.

Could it be that the cause is in EnvVarsResolver.gatherEnvVarsNode? It looks like EnvVars.masterEnvVars is updated directly in that method when the code runs on master.

Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/lib/envinject/service/EnvVarsResolver.java
http://jenkins-ci.org/commit/envinject-lib/ad78b8f1833861e40d4c9d7a56fa7f72ede33bbc
Log:
Merge pull request #3 from wgreven/JENKINS-13348

Don't overwrite masterEnvVars.

Compare: https://github.com/jenkinsci/envinject-lib/compare/1a9def04d4d1...ad78b8f18338

Gregory's patch didn't fix it, the problem still exists.

EnvInject 1.87, Jenkins 1.519

Downgrading to 1.36 to work around it. If I get some time I'll walk through releases to narrow down where the problem started.

Is it possible to just hardcode 'WORKSPACE' as an untouchable variable? Or perhaps an "Advanced" check box to allow overriding core Jenkins variables of any kind?

I don't think all plugins have already been rebuild with the new EnvInject version.

What we did is creating a job which periodically runs the following Groovy system script:

hudson.EnvVars.masterEnvVars.remove('WORKSPACE')

It's not nice, but it minimizes the damage caused by this bug.

I am hitting the same issue. EnvInject 1.89 and jenkins 1.532.3 and WORKSPACE got set into hudson.EnvVars.masterEnvVars which caused lots of strange build issues. This is really a bummer.

I'm hitting the same issue with EnvInject 1.89 and Jenkins 1.553.

Similar problem detected with EnvInject 1.91.1 and Jenkins 1.609. Version 1.90 does not have the problem

For some reason the Path env variable is not updated but java.library.path is. When you try to build, it looks in the old path

Do you still see the problem with the 1.92.1 released on Aug 21 2015?

I have installed 1.92.1 the problem is present.
I have downgraded until 1.38 which is the latest version that doesn't have this defect.

Here a log extract:

Building remotely on quality in workspace /apps/homes/jenkins/node_quality/workspace/sonar_build
[sonar_build] $ /bin/sh -xe /tmp/hudson4867033689412661438.sh
+ echo now Launching the build workspace...
now Launching the build workspace...
+ /apps/tools/misc-tools/build_test.sh
WORKSPACE=/apps/tools/homes/jenkins/node_quality

As you can see WORKSPACE variable is not set correctly

I see this issue as well. EnvInject 1.92.1, jenkins 1.642.1. I originally posted this bug
https://issues.jenkins-ci.org/browse/JENKINS-19754

The work around to get WORKSPACE set correctly is to
○ Select "Prepare jobs environment" on the slave
○ Select "Unset System Environment Variables" on the slave

After recent upgrades on jenkins and plugins I now see intermittent env inject of WORKSPACE to the slave root. I think the "unset system environment variables" is being ignored intermittently. Passing builds have a small set of environment variables set which appear to be only jenkins related. Failing builds have many more environment variables, especially system ones like HOST and LSF environment variables. The passing cases do not have WORKSPACE set.
This is causing a lot of grief for our work. I hope someone can look into it.

I should also note that the job affected by this does not have "Prepare an environment for the run" selected. EnvInject is still lurking though as this message is always present in stdout:
[EnvInject] - Loading node environment variables.