Details
-
Type:
New Feature
-
Status: Reopened (View Workflow)
-
Priority:
Critical
-
Resolution: Unresolved
-
Component/s: matrix-project-plugin
-
Labels:
-
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:
- Jenkins master installed.
- Multiple slave nodes connected to Jenkins master.
- Multiple discrete labels to contain nodes.
Steps to reproduce:
- Create new Jenkins project. (Click "New Item".)
- Give new item a name, and select Multi-Configuration project by selecting "Build multi-configuration project".
- Create at least one user-defined axis with at least two values, e.g. the axis name TestAxis and the values TestValue1 and TestValue2.
- Restrict the project to include one node but exclude all other nodes.
- Under "Advanced Project Options", tick the checkbox "Restrict where this project can be run"
- 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.
- Define a build step of some sort. For simplicity's sake, I used a shell script that simply consisted of one line: echo ${TestAxis}
- 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
- is duplicated by
-
JENKINS-52482 Jenkins using wrong build node using user-defined axis
-
- Open
-
-
-
- Open
-
- is related to
-
JENKINS-9531 choose matrix build nodes based on label matches
-
- Open
-
Activity
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?
Read the preceding comments for suggestions that allow filtering of matrix configurations
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?
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.
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:
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.