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

local variables in shared-library global vars being treated globally

    Details

    • Similar Issues:

      Description

      I have a shared library that defines a global variable provisionNodes.

      Inside that global variable a local variable is defined to hold the value of a passed in parameter:

        nodeString = config['NODELIST']
      

      The following code then optionally reassigns the variable if a subset of nodes is wanted (the logic of below is not really important):

        if (config['node_count']) {
          node_list = config['NODELIST'].split(',')
          node_cnt = node_list.size()
          if (config['node_count'] < node_cnt) {
            // take is blacklisted by Jenkins.
            //new_list = node_list.take(config['clients'])
            new_list = []
            for (ii = 0; ii < config['node_count']; ii++) {
              new_list.add(node_list[ii])
            }
            nodeString = new_list.join(',')
          } else if (config['node_count'] > node_cnt) {
            echo "${config['node_count']} clients requested."
            error "Only ${node_cnt} clients available!"
          }
        }
      ...
      

      And then a bit later that variable is used in a shell command:

            rc = sh script: """./jenkins/test_manager/wait_for_node_ready.py \
                             --nodes=${nodeString} ${woptions}""",
      

      If the global variable provisionNodes is run a number of times in parallel from a parallel block in a Jenkinsfile, the nodeString variable is being shared across all running instances in the parallel block such that the last instance to assign nodeString before they all get to the above code block, is setting the value for all instances and they all end up with same argument of nodes to the above shell call.

      Is this expected?  It's not at all embracing the principle of least surprise if it is. and if it is, how do I get nodesString (and every other variables) local scope back as I would expect it?

        Attachments

          Activity

          Hide
          brianjmurrell Brian J Murrell added a comment -

          Not sure if what is described in the description of this ticket is the expected behaviour and if my solution is the expected solution, so I will leave this open for somebody else to decide and resolve if so.

          What resolved this for me was to def}}ine my variables in my {{provisionNodes "global variable" (i.e. vars/provisionNodes).  That made them act local to provisionNodes.

          Show
          brianjmurrell Brian J Murrell added a comment - Not sure if what is described in the description of this ticket is the expected behaviour and if my solution is the expected solution, so I will leave this open for somebody else to decide and resolve if so. What resolved this for me was to def}}ine my variables in my {{provisionNodes "global variable" (i.e. vars/provisionNodes ).  That made them act local to provisionNodes .
          Hide
          stefanmaurer Stefan Maurer added a comment -

          Brian J Murrell: can you please explain your solution in more detail and/or with some code snippets? How do you define the variables?

          Show
          stefanmaurer Stefan Maurer added a comment - Brian J Murrell : can you please explain your solution in more detail and/or with some code snippets? How do you define the variables?
          Hide
          brianjmurrell Brian J Murrell added a comment -

          Stefan Maurer I'm not sure that code snippets is needed.  The solution is to quite simply add def in front of your variables to make them local.

          Show
          brianjmurrell Brian J Murrell added a comment - Stefan Maurer I'm not sure that code snippets is needed.  The solution is to quite simply add def in front of your variables to make them local.
          Hide
          stefanmaurer Stefan Maurer added a comment -

          Thanks Brian J Murrell. Now I understand. Indeed quiet simple 

          Show
          stefanmaurer Stefan Maurer added a comment - Thanks Brian J Murrell . Now I understand. Indeed quiet simple 

            People

            • Assignee:
              Unassigned
              Reporter:
              brianjmurrell Brian J Murrell
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: