![]() |
|
|
|
|
Issue Type:
|
![Bug]() Bug
|
|
Assignee:
|
Jesse Glick
|
|
Components:
|
workflow-plugin |
|
Created:
|
22/Jan/15 4:00 PM
|
|
Description:
|
StepContext.get(EnvVars) is advertised as an option and when run inside node you would expect it to include all environment variables associated with that Computer, but it does not: it only includes those added by Computer.buildEnvironment (node properties, JENKINS_URL), plus anything extra added by the node step (JENKINS_SERVER_COOKIE). This did not matter to sh steps because LocalLauncher.inherit started with the existing environment variables and just added in the overrides. It also did not matter for env.PATH calls from Groovy because EnvActionImpl was hardcoded as of 8eb96e8 (0.1-beta-7) to look up a Computer as a fallback value.
I think the right fix is to make PlaceholderExecutable do the call to getEnvironment, then make EnvActionImpl look for EnvVars in the context—also giving those precedence over user settings, for consistency with DefaultStepContext.
WorkflowTest.env is also too weak: it does not even test externally set environment variables, does not test per-slave variables (which would presumably require a mock SlaveComputer.getEnvironment override), and does not test EnvVars.override behavior (PATH+X syntax) from a block step.
|
|
Project:
|
Jenkins
|
|
Labels:
|
environment-variables
|
|
Priority:
|
![Major]() Major
|
|
Reporter:
|
Jesse Glick
|
|
|
|
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[email protected].
For more options, visit
https://groups.google.com/d/optout.
