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

choose matrix build nodes based on label matches

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • matrix-project-plugin
    • None

      With matrix (multiconfiguration) build jobs one can select (groups of) slaves to build the job on with the axes. It would be nice if when an axis matches multiple nodes (i.e. a label that applies to more than one node, such as x86_64) the node list could be further filtered by (not) matching more labels.

      For example, say I have a list of nodes with the following labels:

      builder1: el5 x86_64
      builder2: el5 i686
      builder3: el5 x86_64 lab
      builder4: el5 i686 lab

      If one of my axis specifications is "el5" then any one of the above nodes would be selected as a slave to build on. However, what would be nice is to have a further filter on the selected nodes, like "lab", so that even though the axis specification of "el5" would match any of the available 4 nodes, that additional "lab" filter would mean that only builder3 and builder4 are eligible nodes.

          [JENKINS-9531] choose matrix build nodes based on label matches

          Andrew Bayer added a comment -

          Couldn't you use the label specifier "el5 && lab"?

          Andrew Bayer added a comment - Couldn't you use the label specifier "el5 && lab"?

          Brian Murrell added a comment -

          Couldn't you use the label specifier "el5 && lab"?

          If I could, I would. But I don't see how I could. For matrix jobs, I can add axes for the various combinations I want built. How do I specify the kind of free-form eligible node specifier you describe above?

          (As I am sure you know, but for the benefit of others reading here) note that the Combination filter is not the place to do this. That filters the combinations that will actually be built. I don't want to do that. I want to filter the nodes that are eligible for any of the given combinations once a list of nodes has been selected for a given combination.

          I might also want to be able to filter on a negative expression like "!lab" so that some jobs can specify "el5" and be eligible on all 4 builders but others with '!lab" are not allowed to run on the lab labelled builders.

          Brian Murrell added a comment - Couldn't you use the label specifier "el5 && lab"? If I could, I would. But I don't see how I could. For matrix jobs, I can add axes for the various combinations I want built. How do I specify the kind of free-form eligible node specifier you describe above? (As I am sure you know, but for the benefit of others reading here) note that the Combination filter is not the place to do this. That filters the combinations that will actually be built. I don't want to do that. I want to filter the nodes that are eligible for any of the given combinations once a list of nodes has been selected for a given combination. I might also want to be able to filter on a negative expression like "!lab" so that some jobs can specify "el5" and be eligible on all 4 builders but others with '!lab" are not allowed to run on the lab labelled builders.

          Brian Murrell added a comment -

          To add to this, adding a global (i.e. applies to all jobs) level node filter would be useful with a way for individual jobs to override, append to that global filter or remove it. The idea being that if I didn't want any jobs to run on builder3 or builder4 by default, I'd have a global filter of "!lab" but then jobs that can run on any of the builders can clear that filter so that they are not excluded by the global "!lab" filter.

          Brian Murrell added a comment - To add to this, adding a global (i.e. applies to all jobs) level node filter would be useful with a way for individual jobs to override, append to that global filter or remove it. The idea being that if I didn't want any jobs to run on builder3 or builder4 by default, I'd have a global filter of "!lab" but then jobs that can run on any of the builders can clear that filter so that they are not excluded by the global "!lab" filter.

          Phil Miller added a comment -

          This would be very helpful to me as well. I've implemented the slave label axis work-around, but it's a seriously non-scalable hack. It'd be much preferable to have axes represent actual desired configurations, with whatever filters applied, and then separate logic to match enabled configurations with nodes on which to run them.

          Phil Miller added a comment - This would be very helpful to me as well. I've implemented the slave label axis work-around, but it's a seriously non-scalable hack. It'd be much preferable to have axes represent actual desired configurations, with whatever filters applied, and then separate logic to match enabled configurations with nodes on which to run them.

          It's a pity that this never got any traction because a few years later, and here I need it again.

          You know, this RFE is basically boils down to having the "Restrict where this project can be run" option in matrix jobs but it applies to the child jobs, not the parent job. So yes, a new "Restrict where this project can be run" that applies to the child jobs. Perhaps "Restrict where the child jobs of this multiconfiguration project can be run".

          Brian J Murrell added a comment - It's a pity that this never got any traction because a few years later, and here I need it again. You know, this RFE is basically boils down to having the "Restrict where this project can be run" option in matrix jobs but it applies to the child jobs, not the parent job. So yes, a new "Restrict where this project can be run" that applies to the child jobs. Perhaps "Restrict where the child jobs of this multiconfiguration project can be run".

          This is basically the same as JENKINS-22494.

          There seems to be enough demand for this kind of feature. Pity it doesn't seem to be getting any traction.

          Brian J Murrell added a comment - This is basically the same as JENKINS-22494 . There seems to be enough demand for this kind of feature. Pity it doesn't seem to be getting any traction.

          Thanks for linking that. I'm gonna watch it too.

          My workaround has been to setup another Jenkins with a single master and no slaves to do the chain of jobs.

          Alexander Reitzel added a comment - Thanks for linking that. I'm gonna watch it too. My workaround has been to setup another Jenkins with a single master and no slaves to do the chain of jobs.

            Unassigned Unassigned
            brian Brian Murrell
            Votes:
            10 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated: