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

node and label parameters try to allocate flyweight executor when used in Pipeline jobs

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Whenever using the node label paramter plugin to parameterize a Pipeline job it tries to allocate a flyweight executor on the node given as parameter.

      However the Pipeline script itselt seems to be still executed on the master.

      But it still has some influence on the Pipeline execution as - depending on the node selected - sometimes our implicitly loaded global shared Pipeline library cannot be cloned.

      Please check following simple script. Put the node offline before running - you'll see that the Pipeline is waiting for that node. However if you just block the selected node by running some other job it'll still execute. And - anyway - the job should not be blocked until it finally reaches the node block which actually uses that node.

      properties([
          parameters([
              [$class: 'NodeParameterDefinition',
                  allowedSlaves: [],
                  defaultSlaves: [],
                  description: '',
                  name: 'foo',
                  nodeEligibility: [$class: 'AllNodeEligibility'],
                  triggerIfResult: 'multiSelectionDisallowed'
              ]
          ])
      ])
      

        Attachments

          Activity

          Hide
          macdrega Joerg Schwaerzler added a comment -

          Not sure whether this relates to this issue. we found that when using the node or label parameters we need to add a dummy entry in the configuration for each node we'd like to use using the parameter setting the path (Windows machines only):

          Path=${Path}

          If we don't do that cloning any pipeline shared library fails. Git would not find the ssh executable anymore - although the library clone should not relate to the node used in any case.

          Show
          macdrega Joerg Schwaerzler added a comment - Not sure whether this relates to this issue. we found that when using the node or label parameters we need to add a dummy entry in the configuration for each node we'd like to use using the parameter setting the path (Windows machines only): Path=${Path } If we don't do that cloning any pipeline shared library fails. Git would not find the ssh executable anymore - although the library clone should not relate to the node used in any case.
          Hide
          macdrega Joerg Schwaerzler added a comment -

          Today we found some even more strange behavior of the plugin in this matter:

          • One job using the LABEL parameter was started on machine 'vm-008'. However this run for some reason uses a flyweight executor on 'vm-011'. This really puzzles me. I can just assume that - since the label expression would match machine 'vm-011', too - the plugin does not necessarily allocate the very flyweight executor it later used for the actual execution.

          Would be great to at least get some feedback on this topic.

          Show
          macdrega Joerg Schwaerzler added a comment - Today we found some even more strange behavior of the plugin in this matter: One job using the LABEL parameter was started on machine 'vm-008'. However this run for some reason uses a flyweight executor on 'vm-011'. This really puzzles me. I can just assume that - since the label expression would match machine 'vm-011', too - the plugin does not necessarily allocate the very flyweight executor it later used for the actual execution. Would be great to at least get some feedback on this topic.

            People

            Assignee:
            domi Dominik Bartholdi
            Reporter:
            macdrega Joerg Schwaerzler
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: