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.