I am facing the same issue. I made some initialization jobs for slave nodes, which run when the slave starts. A Matrix job forces the installation of multiple JDKs and multiple Maven versions. After that it performs some testing to verify the proper installation of the tools. This Matrix job is triggered by another job that specifies the parameter build on same node for the Matrix job.

Possible solutions:

• All Matrix sub-jobs should inherit this setting by default. This setting can be overridden by choosing a value from the Slaves axis or label expression axis.
• Maybe it is an idea to define also a virtual label same node in the Slaves axis or label expression axis.

NodeLabel Parameter allows to restrict jobs in a such way

I do agree that there are at least two solutions for this problem

• NodeLabel parameter plugin with only one option/slave to be chosen
• add slave axis with only one slave
  but both add additional complexity for maintaining the matrix job. The advanced option "Restrict where this project can be run" should IMHO do exactly this.

I agree that "Restrict where this project can be run" should be inherited by matrix jobs by default. It surprised me when it didn't work.

A nice to have would be to be able to configure it per axis or per particular job. I can see how the job would override the axis, that would in turn override the main job value.

I have a problem using the following situation.

I use a jenkins master and some virtual machines as slaves to start parallel tests.
The virtual machines are configured to use a special test environment (database, WAS, JDK) in every vm.
The test uses a matrix configuration to manage the different test configuration.

At the start of the test every slave VM is resetted to a defined snapshot, to make sure the test conditions are always equal.
After booting the VM, the build, selected for testing is installed on the jenkins slave VMs.
If the Matrix jobs are started on a slave, the testresult is always failure due to the reset to the snapshot of the slave VM and the resultng network error.
So I need the possibility to make sure, all the matrix jobs are started on jenkins master.

Hello,
I think I solved my problem.
I tried to restriced at first the execution of the matrix jobs bei a label expression in the advanced project settings.
But that does not work.
Now I use a simple groovy script to restrict the job to the master.
The script is

<pre>
return "Master";
</pre>

Now all the matrix childs are executed on the jenkins master as I need in my test environment.

Hello @Reiner Writz

Where have you put your script to force execution in the master ?

Thanks

Hello @Reiner Writz

Where have you put your script to force execution in the master ?

Thanks

In the first section of the multiconfiguration is an option to enter a groovy script to restrict where the job could be run.
Activating this option opens an edit field for the groovy script.
In this field I entered the mini groovy script: return "Master";
This worked fine.

the attached png shows the script in a screen shot

@Reiner Writz does that workaround apply for slaves other than "master"? Does it match their labels?

I think I have the same need as @Jordan Spiker, instead of restriction on a node (master for example) I need to restrict builds to a Label.

So the question is: can we use groovy to do such thing ?

Thank you

Have you read the help (question mark at the right side)?

It starts as follow:

Return value from Groovy script is treated as Label Expression. It is treated as followings:

A non-string value will be converted to a string using toString()
When null or blank string is returned, node restriction does not take effect (or is not overwritten).
When exception occurred or Label Expression is not parsed correctly, builds are canceled.

It sounds for me, that the return value "Master" from groovy script is treated as a label for the master node.
But I haven't tried it in my environment.
But if some else tested it, it would be nice to hear from him.

we also experience this with Jenkins ver. 1.612 too
The "Restrict where this project can be run" setting is ignored for a Matrix config.

The above workaround works though: installing the "Groovy Label Assignment plugin" and returning the Label of the desired node works OK.

As far as I understand the behavior, the "restrict where a project can be run" setting only controls the initial "flyweight job" which starts the multi-configuration job. The multi-configuration wiki page has a paragraph describing that behavior and references two plugins which can modify that behavior.

@Peter: Thak You very much for the note, that a plugin is needed for the workaround

I was able to achieve the desired behavior where I can restrict slave jobs to run on certain labels.

I did the following:

1. add the "label expression" axis then add an expression that filters what machines you want to run on
   1. the problem here is that this expression will be used in the workspace name so you have to change the workspace name to avoid run issues due to strange folder names
2. "Use custom child workspace" : specify a unique name per run using the matrix axis names as variables

shmoib can you share a screen shot of your configuration? 

dakang, here you are

1- add the "label expression" axis 

2- "Use custom child workspace" : specify a unique name per run using the matrix axis names as variables

thank you shmoib