Path environment variable not set by SimpleBuildWrapper.Context.env() on Windows slave

[Martin Weber]

Hi all,

in my SimpleBuildWrapper.setup(), I want to add an extra directory to
the PATH-variable by SimpleBuildWrapper.Context.env("Path",<new path>).

The job is configured to run on a windows slave.
Manipulating the PATH works well with Jenkins instances launched by mvn
hpi:run on both Linux and windows.
However, when the Jenkins master is running as a service on Solaris, the
Path variable is not changed.

The Solaris Jenkins master is secured, could that be the cause?
I have no idea what I am doing wrong.

Any ideas?

Jenkins version is 2.60.1.

TIA,
Martin


--
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?

| Martin Weber
| Razorcat Development GmbH
| Witzlebenplatz 4 fon: +49-(30)-536 357 46
| 14057 Berlin fax: +49-(30)-536 357 60
|
|--------------------------------------------
| Geschäftsführer: Michael Wittner
| Sitz der Gesellschaft: Berlin
| Amtsgericht: Berlin, HRB 65326

[Jesse Glick]

On Wed, Jul 5, 2017 at 1:43 PM, Martin Weber <fifteen...@gmail.com> wrote:
> in my SimpleBuildWrapper.setup(), I want to add an extra directory to
> the PATH-variable by SimpleBuildWrapper.Context.env("Path",<new path>).

I think you meant to use `PATH+SOMETHING` as per the Javadoc.

[Martin Weber]

No, I tried PATH+SOMETHING` first, but that put in the wrong path-separator
(':' where ';' is needed, when master is on Linux). The EnvVars object in this
case has platform==null, so EnvVars.override() gets it wrong.
So what I now do is essentially
context.env("Path", myPath + ";"+ initialEnvironment.get("Path") )

I use a windows batch execution to verify the PATH setting (just a DOS PATH
command) and tracked it down until the script launcher was invoked.
The envVars passed to launcher.launch().env() had the extra directory in
$Path.

So it is not a problem that arises wh i run a secured jenkins master?
Maybe one of the plugins installed on my production Jenkins interferes here?

--
Cd wrttn wtht vwls s mch trsr.

[Jesse Glick]

On Wed, Jul 5, 2017 at 3:43 PM, Martin Weber <fifteen...@gmail.com> wrote:
> I tried PATH+SOMETHING` first, but that put in the wrong path-separator
> (':' where ';' is needed, when master is on Linux). The EnvVars object in this
> case has platform==null, so EnvVars.override() gets it wrong.

Uh, really? Is this reproducible in a minimal self-contained test
case? If so, please file a bug report, starting in
`workflow-basic-steps-plugin` for analysis. I cannot spot any flaw in
`CoreWrapperStep` or `DefaultStepContext.get` or
`EnvironmentExpander.getEffectiveEnvironment` or
`ExecutorStepExecution.PlaceholderTask.PlaceholderExecutable.run` or
`Computer.getEnvironment`—they seem to pass along the `platform` of
the agent.

> So what I now do is essentially
> context.env("Path", myPath + ";"+ initialEnvironment.get("Path") )

No do not do that.

> Maybe one of the plugins installed on my production Jenkins interferes here?

Conceivable.

[Daniel Beck]

> On 6. Jul 2017, at 00:27, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> Uh, really? Is this reproducible in a minimal self-contained test
> case?

FWIW I remember a really old bug report about that, maybe this is "known" already.

[15 knots]

2017-07-06 0:27 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:
> On Wed, Jul 5, 2017 at 3:43 PM, Martin Weber <fifteen...@gmail.com> wrote:

...

>> Maybe one of the plugins installed on my production Jenkins interferes here?
>
> Conceivable.

Found the culprit: Environment Injector Plugin
Should I file a bug report?

[15 knots]

Quite new: https://issues.jenkins-ci.org/browse/JENKINS-14807

[Jesse Glick]

On Thu, Jul 6, 2017 at 7:45 AM, 15 knots <fifteen...@gmail.com> wrote:
> Found the culprit: Environment Injector Plugin
> Should I file a bug report?

Ah, yes, I suppose so. One of the unfortunate things about this plugin
(at least in my memory) is its tendency to cause behavioral changes
even on jobs where it has not been configured.

[15 knots]

This is what happens with SimpleBuildWrapper and the Environment
Injector Plugin installed:
- CommandInterpreter.perfom() calls AbstractBuild.getEnvironment().
- getEnvironment() assembles all values from its buildEnvironments
list -- one of these is SimpleBuildWrapper.EnvironmentWrapper. which
inserts my extended value for $Path. Fine.
- After that, EnvironmentContributingActions inject their variables.
One of them is an EnvInjectPluginAction, it overwrites the $Path
variable.

This EnvironmentContributingAction object will overwrite nearly every
variable (Path, JENKINS_URL, ALLUSERSPROFILE, PROCESSOR_ARCHITECTURE,
...).

[Oleg Nenashev]

EnvInject Bug for it: https://issues.jenkins-ci.org/browse/JENKINS-26583
I have a plan to fix it, but right now it is not a top priority for me. The plugin is looking for adopters

четверг, 6 июля 2017 г., 18:30:07 UTC+2 пользователь 15 knots написал:

[Nikolas Falco]

@15knots this issue is not caused by the envinject plugin (I had try this when I got the issue).

As you can see in the JIRA bug the issue is a Jenkins Core class (Run.java) and in the sequence that it use to constructs a new EnvVars for the current node. In the chain of enviroments pouring into others the internal variable (platform) to understand of which kind of OS is the current node is losts. That variable is used later to join file system paths (described in the JIRA Thread).

In the thread I had propose a patch to the Run.java class based on what I have see about the way that EnvVar/Environment pass platform to other EnvVar (but not tested).

A quick workaround for you is install the NodeJS plugin that ships a FixEnvVarEnvironmentContributor (tested in our organisation) that fix the issue until that bug is not resolved. It acts before any other EnvironmentContributor and set the value of internal variable platform of the created getEnviroment() just if and only if it is null.

[15 knots]

2017-07-09 15:40 GMT+02:00 'Nikolas Falco' via Jenkins Developers
<jenkin...@googlegroups.com>:

> @15knots this issue is not caused by the envinject plugin (I had try this
> when I got the issue).

Sorry, I have to disagree here. If I uninstall or disable the
envinject plugin, the issue is gone.

>
> As you can see in the JIRA bug the issue is a Jenkins Core class (Run.java)
> and in the sequence that it use to constructs a new EnvVars for the current
> node. In the chain of enviroments pouring into others the internal variable
> (platform) to understand of which kind of OS is the current node is losts.
> That variable is used later to join file system paths (described in the JIRA
> Thread).

That is a different issue
https://issues.jenkins-ci.org/browse/JENKINS-14807, which causes a
wrong path separator being inserted .