Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Not A Defect
-
None
Description
When having a pipeline task running over multiple nodes in sequence, the PATH environment is not reset when running on the next node. Here is a sample
node('linux'){ env.PATH = "${env.PATH}:/opt/myapp" echo "${env.PATH}" } node('windows'){ env.PATH = "${env.PATH}:c:\\opt\\myapp" echo "${env.PATH}" }
Output:
[Pipeline] node Running on linux in /var/lib/jenkins/jobs/test-job/workspace [Pipeline] { [Pipeline] echo /sbin:/usr/sbin:/bin:/usr/bin:/opt/myapp [Pipeline] } [Pipeline] // node [Pipeline] node Running on windows in c:/jenkins-slave/workspace/test-job [Pipeline] { [Pipeline] echo /sbin:/usr/sbin:/bin:/usr/bin:/opt/myapp:c:\opt\myapp [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS
The PATH variable is wrong when it proceeds to the second (Windows) node.
I'd expect the PATH to be whatever the Windows PATH is currently set to on the node, plus the extra path I wanted to inject.
Attachments
Issue Links
- is related to
-
-
- Closed
-
Activity
Chris Williams
added a comment - jglick Hey Jesse, I get that it's a no-no to try and modify the env global across multiple nodes. I'm curious what the expectations/best practices are for builds where we use multiple nodes and expect that the local env vars would be available within that node block scope.
i.e. I start a build on a "generic" node which does the checkout, some initial setup and stashes the results, then fires off parallel branches to run on different OSes/platforms with that source. I'm seeing that the env vars sent down to sh calls are actually coming from the initial node the job started on, which was a little surprising. (I have env vars set to point to things like Android NDK/SDK install paths on boxes, etc. it feels odd to have to explicitly run a shell script to get the real value from the node and then pass that into a withEnv block.)
Chris Williams
added a comment - jglick Hey Jesse, I get that it's a no-no to try and modify the env global across multiple nodes. I'm curious what the expectations/best practices are for builds where we use multiple nodes and expect that the local env vars would be available within that node block scope.
i.e. I start a build on a "generic" node which does the checkout, some initial setup and stashes the results, then fires off parallel branches to run on different OSes/platforms with that source. I'm seeing that the env vars sent down to sh calls are actually coming from the initial node the job started on, which was a little surprising. (I have env vars set to point to things like Android NDK/SDK install paths on boxes, etc. it feels odd to have to explicitly run a shell script to get the real value from the node and then pass that into a withEnv block.) 
As explained in the tutorial, do not modify env.ANYTHING_PLATFORM_SPECIFIC. Use the withEnv step instead.