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

Multiconfiguration project does not respect label restrictions

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When running a multi-configuration project defined in Jenkins, it does not respect the "Label Expression" to "Restrict where this project can be run" under the project's "Advanced Project Options" configuration. If multiple slaves nodes exist, but are not included in the Label Expression for the project, they can still be sent build configurations anyway, which can result in build failures or erroneous builds made in incorrect environments.

      Prerequisites:

      1. Jenkins master installed.
      2. Multiple slave nodes connected to Jenkins master.
      3. Multiple discrete labels to contain nodes.

      Steps to reproduce:

      1. Create new Jenkins project. (Click "New Item".)
      2. Give new item a name, and select Multi-Configuration project by selecting "Build multi-configuration project".
      3. Create at least one user-defined axis with at least two values, e.g. the axis name TestAxis and the values TestValue1 and TestValue2.
      4. Restrict the project to include one node but exclude all other nodes.
        1. Under "Advanced Project Options", tick the checkbox "Restrict where this project can be run"
        2. Refer to the labels you have defined from the above pre-requisite and use a label which refers only to one node. Optionally, use the specific node's name, e.g. if a node is named TestNode1, use this value.
      5. Define a build step of some sort. For simplicity's sake, I used a shell script that simply consisted of one line: echo ${TestAxis}
      6. Run the project.

      Results:
      The project's build configuration will be sent to slave nodes other than the ones explicitly defined in the "Restrict where this project can be run" configuration.

      Expected results:
      Label restrictions are enforced/respected on Multi-Configuration Projects, as they are on other project types.

      Notes:

      • Even using a label expression such as TestNode1 && !TestNode2, project configurations were still sent to TestNode2 to be built.
      • A workaround is to add the Slaves axis to the project's configuration matrix, and select which slaves nodes to use there, and to not use label restriction in Advanced Project Options.
      • This is not a duplicate of the quite similar issue JENKINS-5987, as it described repository checkouts occurring on incorrect nodes, and does not describe the steps listed above.

        Attachments

          Issue Links

            Activity

            Hide
            legolas Arnt Witteveen added a comment - - edited

            I would like to add my reasons on why a way to specify where to run the eventual builds (and where not) is also needed, independent from the axis'.

            I have a master with no compiler, and several slaves with compilers. I want my build to be build in (let's see the example simple) 2 flavors, so I define 1 axis with flavor1 and flavor2 as the value. Every slave can build each of the flavors, they are just different build settings (think building with different defines in C/C++). However, for speed, I would like my 2 builds to run on 2 separate slaves if they are free. And they cannot be run on the master.

            As I see it, there is no solution for this currently: Adding a 'slave' axis makes no sense, I don't want each combination of the other axis to be build on each slave, I only want to build each combination of my axis to be build once. And I don't want to lock certain combinations to certain build machines, these machines might be busy while others are idle, and of course I'd want to use the idle machines then.

             

            My trials may help others:

            • I've tried the 'NodeLabel Parameter Plugin' suggested in JENKINS-23459 . This make the build a paramterized build, which is something I don't want.
            • I had success using the 'Groovy Label Assignment plugin' suggested above, using this script to keep the 'flyweight job' (that starts the axis combination jobs) on the master, and run the actual builds on any node with a label 'CanRunMainBuild' (which could be refined further to run only certain axis on certain node labels, if you need it):

            if (currentJob.getClass().toString() == "class hudson.matrix.MatrixProject")

            { // for the matrix "parent/flyweight" job return "master"; }

            else

            { // for the child jobs return "CanRunMainBuild"; }

            However, now slaves run all the subjobs simultaneously, and the Throttle concurrent builds plugin doesn't block that when using the 'Throttle this project alone' functionality. I think this is JENKINS-33940, and the suggested workaround there (use a category) does work.

            Show
            legolas Arnt Witteveen added a comment - - edited I would like to add my reasons on why a way to specify where to run the eventual builds (and where not) is also needed, independent from the axis'. I have a master with no compiler, and several slaves with compilers. I want my build to be build in (let's see the example simple) 2 flavors, so I define 1 axis with flavor1 and flavor2 as the value. Every slave can build each of the flavors, they are just different build settings (think building with different defines in C/C++). However, for speed, I would like my 2 builds to run on 2 separate slaves if they are free. And they cannot be run on the master. As I see it, there is no solution for this currently: Adding a 'slave' axis makes no sense, I don't want each combination of the other axis to be build on each slave, I only want to build each combination of my axis to be build once. And I don't want to lock certain combinations to certain build machines, these machines might be busy while others are idle, and of course I'd want to use the idle machines then.   My trials may help others: I've tried the 'NodeLabel Parameter Plugin' suggested in JENKINS-23459 . This make the build a paramterized build, which is something I don't want. I had success using the 'Groovy Label Assignment plugin' suggested above, using this script to keep the 'flyweight job' (that starts the axis combination jobs) on the master, and run the actual builds on any node with a label 'CanRunMainBuild' (which could be refined further to run only certain axis on certain node labels, if you need it): if (currentJob.getClass().toString() == "class hudson.matrix.MatrixProject") { // for the matrix "parent/flyweight" job return "master"; } else { // for the child jobs return "CanRunMainBuild"; } However, now slaves run all the subjobs simultaneously, and the Throttle concurrent builds plugin doesn't block that when using the 'Throttle this project alone' functionality. I think this is JENKINS-33940 , and the suggested workaround there (use a category) does work.
            Hide
            shai_shap Shai Shapira added a comment -

            Any plans to fix this?

            If binding using Node axis, is there any workaround that does not require running all configurations on all nodes with label?

            Show
            shai_shap Shai Shapira added a comment - Any plans to fix this? If binding using Node axis, is there any workaround that does not require running all configurations on all nodes with label?
            Hide
            markewaite Mark Waite added a comment -

            Read the preceding comments for suggestions that allow filtering of matrix configurations

            Show
            markewaite Mark Waite added a comment - Read the preceding comments for suggestions that allow filtering of matrix configurations
            Hide
            shai_shap Shai Shapira added a comment -

            Thanks. I read it, but it does not allow the run of each configuration on one host only.

            i.e. If I have 2 config values, and 4 potential build agents, creating a 2x4 would run 8 jobs, instead of 2.

            Is there a way to solve this?

            Show
            shai_shap Shai Shapira added a comment - Thanks. I read it, but it does not allow the run of each configuration on one host only. i.e. If I have 2 config values, and 4 potential build agents, creating a 2x4 would run 8 jobs, instead of 2. Is there a way to solve this?
            Hide
            markewaite Mark Waite added a comment -

            Shai Shapira all the details of using exclusions are included in the comments.

            If that's not enough, you might consider switching to the Jenkins pipeline. Blog posts for Declarative pipeline and scripted pipeline describe the techniques to define matrix configurations and to exclude portions of the matrix.

            Show
            markewaite Mark Waite added a comment - Shai Shapira all the details of using exclusions are included in the comments. If that's not enough, you might consider switching to the Jenkins pipeline. Blog posts for Declarative pipeline and scripted pipeline describe the techniques to define matrix configurations and to exclude portions of the matrix.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              courtlandj Courtland Jones
              Votes:
              25 Vote for this issue
              Watchers:
              35 Start watching this issue

                Dates

                Created:
                Updated: