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

"Restrict where this project can be run"-Option not available for Matrix builds

      Hi,

      were facing this annoying Problem since several months.
      We're having a Matrix Build that can only be run successfully on the Master Hudson Node.
      But every time a Slave Node is online and this build is started it starts on the Slave-Node and of course fails.
      So we wanted to set this Matrix-Build to only run on Master-Hudson-Node but this option is not available in the configuration Page.

      Is it possible to make this option available for matrix build jobs ?

      thanks in advance,

      Robert

          [JENKINS-7683] "Restrict where this project can be run"-Option not available for Matrix builds

          kbertelson added a comment -

          Maybe the matrix "parent" build is causing your problems.

          The "Configuration Matrix" portion of a Multi-configuration job lets you determine where everything gets executed except for the "parent" build. By default, Hudson will run the parent build on a node based on an internal algorithm. This could include a slave node that can't run the parent build. That may be your problem. If it is, you can fix the issue by installing the "Matrix Tie Parent" plugin. This would allow you to force Hudson to run your parent build always on your Master Hudson Node.

          See: http://wiki.jenkins-ci.org/display/JENKINS/Matrix+Tie+Parent+Plugin

          kbertelson added a comment - Maybe the matrix "parent" build is causing your problems. The "Configuration Matrix" portion of a Multi-configuration job lets you determine where everything gets executed except for the "parent" build. By default, Hudson will run the parent build on a node based on an internal algorithm. This could include a slave node that can't run the parent build. That may be your problem. If it is, you can fix the issue by installing the "Matrix Tie Parent" plugin. This would allow you to force Hudson to run your parent build always on your Master Hudson Node. See: http://wiki.jenkins-ci.org/display/JENKINS/Matrix+Tie+Parent+Plugin

          heinzepreller added a comment -

          It works ! This Plugin did the job, thanks.

          heinzepreller added a comment - It works ! This Plugin did the job, thanks.

          Andy M added a comment -

          It doesn't seem like a plugin should be required for this. It's basic functionality.

          Andy M added a comment - It doesn't seem like a plugin should be required for this. It's basic functionality.

          Don Ross added a comment -

          I am encountering this same problem; however, it is not the parent job that it is the problem, it is that all of my matrix jobs are running on the master when I want them to run on specific slaves.

          On other jobs, I set the 'Restrict where this project can be run' to "NODE1 | NODE2 | NODE3" (etc), and the job runs on whichever system is available.

          When setting up a matrix job, I see no way to do this except to create an additional axis. But, if I do that, then I get a two-dimensional matrix, and each of my configurations runs once on each host.

          What am I supposed to do in this situation?

          Don Ross added a comment - I am encountering this same problem; however, it is not the parent job that it is the problem, it is that all of my matrix jobs are running on the master when I want them to run on specific slaves. On other jobs, I set the 'Restrict where this project can be run' to "NODE1 | NODE2 | NODE3" (etc), and the job runs on whichever system is available. When setting up a matrix job, I see no way to do this except to create an additional axis. But, if I do that, then I get a two-dimensional matrix, and each of my configurations runs once on each host. What am I supposed to do in this situation?

          kbertelson added a comment -

          Take a look at the "Combination Filter" feature of a matrix project. The help text tells you how to fine-tune which configurations to run on which host.

          kbertelson added a comment - Take a look at the "Combination Filter" feature of a matrix project. The help text tells you how to fine-tune which configurations to run on which host.

          Don Ross added a comment -

          Okay, that does work. A little clumsy, but an acceptable workaround.

          Don Ross added a comment - Okay, that does work. A little clumsy, but an acceptable workaround.

          Kevin R. added a comment -

          Bump.
          Having this feature would be nice

          Kevin R. added a comment - Bump. Having this feature would be nice

          Jonathan Rice added a comment -

          I think I'm hitting the same issue as the original poster. Perhaps I can clarify the failure scenario. Say you have a matrix build called "Matrix", with a single axis of user-defined values "p1", "p2", ... "p5". And say you want all of that build to run on the Master node, and not on another slave node "node1". AFAICS, six tasks are kicked off for such a build - the parent (flyweight) task "Matrix", plus a task for each configuration in the matrix: "Matrix >> p1", "Matrix >> p2", ... "Matrix >> p5". Now, with the "Matrix Tie Parent" plugin, you can succeed in pinning the parent task "Matrix" to the Master node, but this has no effect on the per-configuration tasks "Matrix >> p1", etc. So some of those will tend to run on the slave node "node1". I have not found any way to restrict where these tasks are run, as can be easily done with non-matrix jobs.

          Jonathan Rice added a comment - I think I'm hitting the same issue as the original poster. Perhaps I can clarify the failure scenario. Say you have a matrix build called "Matrix", with a single axis of user-defined values "p1", "p2", ... "p5". And say you want all of that build to run on the Master node, and not on another slave node "node1". AFAICS, six tasks are kicked off for such a build - the parent (flyweight) task "Matrix", plus a task for each configuration in the matrix: "Matrix >> p1", "Matrix >> p2", ... "Matrix >> p5". Now, with the "Matrix Tie Parent" plugin, you can succeed in pinning the parent task "Matrix" to the Master node, but this has no effect on the per-configuration tasks "Matrix >> p1", etc. So some of those will tend to run on the slave node "node1". I have not found any way to restrict where these tasks are run, as can be easily done with non-matrix jobs.

          Jonathan Rice added a comment -

          Ah, I figured out two work-arounds. The first solution, which had been staring me in the face, and I think may have been implied in one or two previous comments, is to add a "Slaves" matrix axis with just one value, "master". This makes all of the per-configuration jobs run on the master. Combined with the "Matrix Tie Parent" plugin, to also tie the parent task to "master", we then have all jobs running on the master, and not on any slave nodes. The second solution is to use the "NodeLabel Parameter" plugin, to add a node parameter "master" to the matrix build. This also makes all of the per-configuration jobs run on the master, and with the "Matrix Tie Parent" plugin once again taking care of tying the parent job to the master, we have a full solution.

          Jonathan Rice added a comment - Ah, I figured out two work-arounds. The first solution, which had been staring me in the face, and I think may have been implied in one or two previous comments, is to add a "Slaves" matrix axis with just one value, "master". This makes all of the per-configuration jobs run on the master. Combined with the "Matrix Tie Parent" plugin, to also tie the parent task to "master", we then have all jobs running on the master, and not on any slave nodes. The second solution is to use the "NodeLabel Parameter" plugin, to add a node parameter "master" to the matrix build. This also makes all of the per-configuration jobs run on the master, and with the "Matrix Tie Parent" plugin once again taking care of tying the parent job to the master, we have a full solution.

          Phil Miller added a comment -

          #9531 proposes a particular form of solution to this issue

          Phil Miller added a comment - #9531 proposes a particular form of solution to this issue

            Unassigned Unassigned
            heinzepreller heinzepreller
            Votes:
            5 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: