On 27.04.2012 22:43, Grégory Boissinot wrote:
On Fri, Apr 27, 2012 at 11:10 AM, John Vacz
<mailing.list.collect...@googlemail.com
<mailto:mailing.list.collect...@googlemail.com>> wrote:
ToolEnv detects the tools installed automatically without extra
configuration and populated the path into variables with
predicatable name, this is a nice feature for our slave-only setting.
SharedObjects provides exactly the same feature (and more) without any
extra configuration.
Procedure:
- Install EnvInject plugin and the complement shared objects plugin.
- From the EnvInject configuration
> Prepare an environment for the run > EnvInject Contributions >
check Populate Tool Installations
Path installation will be populated automatically.
Nice! Somehow I managed to completely oversee this option... This
feature is the exact reason why I installed ToolEnv plugin, now I can
happly remove it completely.
Thanks for the great work and explanation!
It's somehow more "dynamic" than EnvInject from this point of view.
It is your point of view.
Can you give me some suggestion how can I achieve the similar with
ShareObjects/EnvInject?
Feel free to report a feature request to the ToolEnv plugin.
Done
As someone has suggested before, it would be very nice if ToolEnv
and EnvInject can be merged together.
Am 27.04.2012 08 <tel:27.04.2012%2008>:34, schrieb Grégory Boissinot:
At the moment, ToolEnv is not aware of the EnvInject plugin.
Technically ToolEnv doesn't export its new environment variables
by an EnvironmentContribution action.
Therefore, EnvInject cannot capture environment variables
populated by the ToolEnv plugin.
However, you can install the SharedObjects plugin (this plugin is
a complement to the EnvInject plugin by providing the ability to
shared objects as environment variables. These objects can be
Tools and their installation paths are exposed as environment
variables.
On Thu, Apr 26, 2012 at 11:13 PM, John Vacz
<mailing.list.collect...@googlemail.com
<mailto:mailing.list.collect...@googlemail.com>> wrote:
Jenkins 1.460, debian native package (winstone)
EnvInject 1.46
ToolEnv 1.0
-------- Original Message --------
Subject: EnvInject does not pick up variables injected by
ToolEnv plugin
Date: Thu, 26 Apr 2012 23:04:24 +0200
From: John Vacz <mailing.list.collect...@googlemail.com>
<mailto:mailing.list.collect...@googlemail.com>
To: Jenkins Users <jenkinsci-users@googlegroups.com>
<mailto:jenkinsci-users@googlegroups.com>
A trival job:
1. ToolEnv injected a enviroment variable "JDK_1_6_HOME",
2. build step 1: shell script: echo " -- Before envinject:
JDK1_6_HOME=$JDK1_6_HOME"
3. build step 2: EnvInject injected another variable
SOME_ARG=$JDK1_6_HOME
Console output:
Started by user tester
[EnvInject] - Loading node environment variables.
Building remotely onslave4
<https://comitdev1/jenkins/computer/comitdev4> in workspace
/home/jenkins-slave/jenkins-slave-fs-root/workspace/envinject-vs-toolenv
Setting
JDK1_6_HOME=/home/jenkins-slave/jenkins-slave-fs-root/tools/jdk1.6/jdk1.6.0_26
[envinject-vs-toolenv] $ /bin/sh -xe /tmp/hudson2392984131553273240.sh
+ echo -- Before envinject:
JDK1_6_HOME=/home/jenkins-slave/jenkins-slave-fs-root/tools/jdk1.6/jdk1.6.0_26
-- Before envinject:
JDK1_6_HOME=/home/jenkins-slave/jenkins-slave-fs-root/tools/jdk1.6/jdk1.6.0_26
[EnvInject] - Injecting environment variables from a build step.
[EnvInject] - Injecting as environment variables the properties content
SOME_ARG=$JDK1_6_HOME
[EnvInject] - Variables injected successfully.
[EnvInject] - Unset unresolved 'SOME_ARG' variable.
Notifying upstream projects of job completion
Finished: SUCCESS
Build step 1 shows that $JDK1_6_HOME was correctly injected,
but EnvInject in build step 2 did not pick up the variable
injected by ToolEnv plugin in pre-build stage. Variable
SOME_ARG remains empty. Is this a bug of EnvInject or just my
misunderstanding?
-- jv
