Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-44425

global variables overwrite node variables

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: pipeline
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.46.2
    • Similar Issues:

      Description

      Since latest upgrade of (pipeline) plug-ins, global variables take precedence over variables defined by nodes. Before the update it was possible for a node to override a global variable and adjust it to the local needs.

      Might be related to the changes made for JENKINS-43396, amongst others the Pipeline: Job plug-in was updated from 2.10 to 2.11 on our system

        Attachments

          Issue Links

            Activity

            Hide
            michelzanini Michel Zanini added a comment -

            Can we look at this issue again? It's being open for quite a while. I encountered this today and was really confused. I follow the docs saying that the env variable on the node should override the globals, but that's not what happens. Maybe we should do what Jesse Glick mentioned and revert that other issue as this seems more important then being that issue in the first place.
            Thanks.

            Show
            michelzanini Michel Zanini added a comment - Can we look at this issue again? It's being open for quite a while. I encountered this today and was really confused. I follow the docs saying that the env variable on the node should override the globals, but that's not what happens. Maybe we should do what Jesse Glick mentioned and revert that other issue as this seems more important then being that issue in the first place. Thanks.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            pavake Pascal van Kempen added a comment -

            I tend to disagree with Jesse Glick. 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)

            Show
            pavake Pascal van Kempen added a comment - I tend to disagree with Jesse Glick . 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)
            Hide
            daniel1zhang daniel zhang added a comment -

            We encountered the same issue and it happens after the Pipeline: Job plugin version 2.25. And I tend to agree with Pascal van Kempen. If we are going to create a new pipeline job, then we can follow the method provided by  Jesse Glick, 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.

            Show
            daniel1zhang daniel zhang added a comment - We encountered the same issue and it happens after the Pipeline: Job plugin version 2.25. And I tend to agree with Pascal van Kempen . If we are going to create a new pipeline job, then we can follow the method provided by   Jesse Glick , 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.
            Hide
            gremlinmaster David Wolff added a comment - - edited

            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.

            Show
            gremlinmaster David Wolff added a comment - - edited 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.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              gordin Christoph Vogtländer
              Votes:
              29 Vote for this issue
              Watchers:
              36 Start watching this issue

                Dates

                Created:
                Updated: