Again—I recommend not touching the current logic.

If you want to control environment variables used during builds, use the withEnv step or an equivalent, or simply set variables inside shell scripts. Steer clear of node properties and Jenkins global configuration.

I tend to disagree with jglick. We are currently migrating some concepts from traditional builds to pipelines, and due to different environments we have some nodes with local variables overwriting the global ones. 

It's a pain in the <peep> now sometimes to figure out why migrated builds don't work anymore, as the behavior of the node changes (while we were initially suspecting our own scripts)

We encountered the same issue and it happens after the Pipeline: Job plugin version 2.25. And I tend to agree with pavake. If we are going to create a new pipeline job, then we can follow the method provided by  jglick, but if we already have a lot of jobs at Jenkins, then we have to ask all users to check and modify their jobs, this will be a huge disaster to users.

I don't get that.

The jenkins help clearly says that the Environment variables section from the Node Properties will overwrite the one from the Configure System page.
So either the logic or the documentation should be changed.

Although from my point of view it is more reliable to have environment variables like JAVA_HOME that can be used by scripts then setting these environment variables inside the script.
If I set them inside scripts I am bound to a fixed path and the script can't be executed on systems where this path doesn't exist. If I use the environment variable that the system defines it is irrelevant where java has been installed.

Unfortunately using the withEnv step also doesn't solve the problem. In our setup we are building on the master as well on the agents but need
a different configuration for the agents.

In our case if a developer decides to build his feature branch he starts a vm that automatically connects to jenkins as an agent.
To make it easy for the developer to find his agent the hostname of the developers pc is incorporated into the agent name.

Therefore it's not possible to check for the agent name in Jenkinsfiles and use different environment settings because I don't know the name of the Agent.

Hi, any updates on this issues? Would be really nice to have it fixed.

Stumbled across that issue too and now I'm wondering why in 5 years noone seemed to take interest in fixing it and JENKINS-54767 has been abandoned after been in review for almost a year.

Got the same issue.. oO whats going on here?

I ran into this issue and our workaround was to unset all the global variables and set them on each node instead. The built-in node of controller also has a configuration for setting environment variables so they can be applied there instead of globally.

It's unfortunate that a regression of this type would stay unresolved/unfixed. We are working around the issue by using kisielk's suggestion of unsetting global variables and instead setting at the node-level.

so... either fix the bug (which right now it is) or fix the doc in jenkins itself that say that agent level variables should indeed override system level variables (after which point it wont be a bug anymore!)

so...  which fix shall we expect ?