-
New Feature
-
Resolution: Unresolved
-
Critical
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.
- 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
-
[JENKINS-22494] Multiconfiguration project does not respect label restrictions
Michael Rose
made changes -
| Affects Version/s | New: current [ 10162 ] |
I believe that the "Restrict where this project can be built" in the Advanced section of a multi-configuration project only limits where the initial flyweight task can execute. I think that the intent is that other areas of the multi-configuration job will be used to control the configuration and the location of the execution tasks. At least, I think that's what I've observed in my use of multi-configuration jobs.
This seems to be borne out with tests of my own; essentially you must use both "Restrict where this project can be built" as Mark Waite says, for the initial task, as well as using the Slaves axis, to control the execution. Forgive me if I have missed it, but, this seems to be documented nowhere.
My apologies that it isn't documented anywhere. I'm sure I read it somewhere, but I could not find a reference in any of the places I checked. I think that confirms your statement that it is documented nowhere.
Would you be willing to describe it on the "Building a matrix project wiki page"?
Sure thing, added my edit.
With this info, I'd consider this issue resolved. Thanks, Mark!
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Martin Skinner
added a comment - I know this issue is closed, but I would like to add my 2c. Perhaps we should consider re-opening this as a feature request. The jobs of a configuration project should 'inherit' the "Restrict where this project can be built" restrictions. These restrictions should apply in addition to any further restrictions in the matrix axes
This would have the following advantages:
- It's expected behavior. Only restricting the flyweight task surprises most people. (Why would I want to do that anyway?)
- Project-wide restrictions ('these jobs need a node with opengl') can be separated from the matrix axes (e.g. release/debug on linux/windows/osx).
- The single-value Label Axis work-around would be unnecessary. This work-around is also cumbersome: it makes passing artifacts between projects more 'brittle' since changing a restriction changes the artifact paths for all downstream projects.
Martin Skinner
added a comment - I know this issue is closed, but I would like to add my 2c. Perhaps we should consider re-opening this as a feature request. The jobs of a configuration project should 'inherit' the "Restrict where this project can be built" restrictions. These restrictions should apply in addition to any further restrictions in the matrix axes
This would have the following advantages:
It's expected behavior. Only restricting the flyweight task surprises most people. (Why would I want to do that anyway?)
Project-wide restrictions ('these jobs need a node with opengl') can be separated from the matrix axes (e.g. release/debug on linux/windows/osx).
The single-value Label Axis work-around would be unnecessary. This work-around is also cumbersome: it makes passing artifacts between projects more 'brittle' since changing a restriction changes the artifact paths for all downstream projects.
Martin Skinner
added a comment - changing from bug to feature request Martin Skinner
made changes -
| Resolution | Original: Not A Defect [ 7 ] | |
| Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
I have noticed the same problem on version 1.560 of Jenkins. I have a multi-configuration project that I restricted to run on nodes with a windows label, but one of the configurations failed b/c it was run on the master (a linux system w/ no labels set).