-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
Jenkins Master: 1.432, hosted on a centos5.3, 32-bit
Slave Node: Windows XP
EnvInject: 1.38
We were using EnvInject 1.35 in various free-style jobs, but after we upgraded to 1.36 jobs started failing.
This is the reason:
1) On the slave node (in this case, a windows XP slave node) JAVA_HOME is pointing to version 1.25. I can verify this by going to Jenkins->Manage Jenkins->Manage Nodes->MyWinXPNode->"view log", and sure enough the node's environment variables have JAVA_HOME pointing to 1.25
2) After upgraded to EnvInject 1.36, the jobs started failing because JAVA_HOME has been overwritten to 1.27, which does not exist on the node. In fact, I don't know where this is being set because the master does not have java 1.27 either!
The only option that is is present in the job is this:
Inject environment variables to the build process
Properties Content:
TEMP=c:\\windows
temp
TMP=c:\\windows
temp
(everything else under "Inject Environment Variables" is blank.
I have not tried the latest version, 1.38, but I will, since all the jobs are currently broken and I have nothing else to lose...
If it doesn't fix it, then the workaround is to go to EnvInject 1.35, but that does not work on multiconfiguration jobs.
I'll keep you posted. If this is fixed in 1.38, I will update this Jira.
[JENKINS-13136] Environment Variable Injection injecting (and overriding) unwanted variables (ie JAVA_HOME)
Gregory Boissinot
added a comment - Please could you test with EnvInject 1.41?
I can't reproduce it.
Gregory Boissinot
added a comment - Please could you test with EnvInject 1.41?
I can't reproduce it. sure. I will install 1.41 and let you know.
I suspect it is because we installed 1.35, then 1.38, and then back down to 1.35.
thanks!
Gregory Boissinot
added a comment - Ok I'm waiting your tests.
Thanks Sorry for the delay. They don't want me messing with production Jenkins.
I'm in the process of creating a mirror image of that Jenkins machine so I can "play around".
Hopefully I'll get it done by today.
Gregory Boissinot
added a comment - Ok let me know when your results will be available. Unfortunately no, except the problem is still there. I can reproduce it. We had some users report that the they are not using any environment injection options at all, and that their environment is still corrupt (the only clue is that they are using Perforce instead of SVN, but personally I don't think that is related). I cannot reproduce it on a clean Jenkins install too. There must be something in our environment that is causing this problem, or some other plugin that is interfering. I'm thinking about installing the latest version, since there is nothing to lose. I'm completely up for suggestions. I'm thinking about installing all the plugins of our production Jenkins on my test Jenkins to see if the problem occurs.
Gregory Boissinot
added a comment - I don't really know what is the best way to solve it.
I can just give you some recommendations such as to avoid to have too many plugins because :
- You have to follow deeply plugins updates
- You don't know exactly what plugins is responsible when there is a problem.
Is it possible to close the issue (maybe temporary) waiting you reproduce the problem?
Gregory Boissinot
added a comment - I don't really know what is the best way to solve it.
I can just give you some recommendations such as to avoid to have too many plugins because :
You have to follow deeply plugins updates
You don't know exactly what plugins is responsible when there is a problem.
Is it possible to close the issue (maybe temporary) waiting you reproduce the problem? Yes. This JIRA should be closed. I can't reproduce it on our test instance either. If I can ever find a way to reproduce it, then I can re-open it with some detailed information. Thank you so much for your time and patience!
Unfortunately no.
In the first project (this is the "virgin" project with nothing checked) I see the PATH variable containing stuff from Jenkins master). JAVA_HOME env is fine.
The second project (where I am using the EnvInjec to inject "foo=bar" I see the PATH variable being tweaked the same as the first project, but it also incorrectly contains JAVA_HOME pointing to Jenkins master.
I did a diff between the injectEnvVars.txt (which are in the zip file that I provided too), and they are indeed different. The moment I use the EnvInject to simply inject "foo=bar", I get every single env var from Jenkins Master. I think that is the root cause.
Its kinda weird that for virgin projects (not using any plugins) the PATH variable is being tweaked from stuff on the master.
If you want I can upgrade from 1.35 to 1.38 (again) and re-run this experiment.
Thanks for looking into this!