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

Matrix jobs are blocked when using labels for nodes

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: vsphere-cloud-plugin
    • Labels:
      None
    • Environment:
      Vphere-cloud-plugin 2.16
    • Similar Issues:

      Description

      When matrix jobs are using node labels, the builds are always pending even if nodes are available with the specified labels.

      When using nodes names, the builds are ok.

      In the first case, if we execute the script https://support.cloudbees.com/hc/en-us/articles/235690727-Why-are-jobs-on-the-queue-when-there-are-dedicated-slaves-with-free-executors , the logs are filled with the following cause :

      JobOffer[Nodes-xxxx-1 #0] refused hudson.model.Queue$BuildableItem:hudson.matrix.MatrixProject@1c83d0a1[XXXX_xx]:46
      because of Don't run FlyweightTask on vSphere node.

        Attachments

          Activity

          Hide
          directhex Jo Shields added a comment -

          With matrix jobs, Jenkins first spawns a "flyweight" job that doesn't consume an executor slot, which does a git checkout of the code (to determine the commit revision of your build), then spawns builds on the axes named in the job. Within the job config, the flyweight runs where the "Restrict where this project can be run" value is set. No actual work, beyond a git checkout, happens on this named node!

           

          Have you tried setting this value to master, and relying on label definitions in your Matrix "Configuration axis" setup only? Blocking flyweight jobs from VSphere nodes seems vaguely reasonable to me.

          Show
          directhex Jo Shields added a comment - With matrix jobs, Jenkins first spawns a "flyweight" job that doesn't consume an executor slot, which does a git checkout of the code (to determine the commit revision of your build), then spawns builds on the axes named in the job. Within the job config, the flyweight runs where the "Restrict where this project can be run" value is set. No actual work, beyond a git checkout, happens on this named node!   Have you tried setting this value to master, and relying on label definitions in your Matrix "Configuration axis" setup only? Blocking flyweight jobs from VSphere nodes seems vaguely reasonable to me.
          Hide
          pjdarton pjdarton added a comment -

          What Jo Shields said - VSphere VMs can be turned off by the plugin, so it's not good to run flyweight tasks on them.  The flyweight job shouldn't even be checking out the code as that's only there to spawn the matrix sub-builds which do the real work.

          Personally I consider it best-practice to tie the matrix build to "master" and then use a "Label expression" matrix axis to dictate where the "real work" happens.

          Show
          pjdarton pjdarton added a comment - What Jo Shields said - VSphere VMs can be turned off by the plugin, so it's not good to run flyweight tasks on them.  The flyweight job shouldn't even be checking out the code as that's only there to spawn the matrix sub-builds which do the real work. Personally I consider it best-practice to tie the matrix build to "master" and then use a "Label expression" matrix axis to dictate where the "real work" happens.

            People

            • Assignee:
              Unassigned
              Reporter:
              dionyweb Fabrice Robin
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: