Any update on this issue? We are also experiencing the same problem.

200$ is up for grabs for solving this issue, see https://freedomsponsors.org/issue/609/job-with-nodelabel-parameter-plugin-does-not-build-in-parallel-on-all-nodes-which-share-a-label?alert=SPONSOR

Hello Christian,

I have dealt with this issue. I am actually giving a presentation on it later this month.

I don't believe it's a bug/issue as much as a design decision, with the idea being that if a single machine can pass a build, why run it on an identical machine?

Here is my solution:
Summary: We have a parent job that finds all online nodes that match a certain label, then foreach node, pass a downstream job a label specific to that node. We have the NodeLabel Parameter plugin installed.

Details:
We have 40 nodes named 'hl-combo-##' where ## is 01-40. Each of those nodes is also labelled 'harnesslab' and 'hl-combo-##'. In a parent job, using groovy, we search all online nodes that have that label:

jenkins.model.Jenkins.instance.nodes.each {
	if (it.toComputer().online && it.assignedLabels.contains(new hudson.model.labels.LabelAtom('harnesslab'))) {
		harnesslabOnlineNodes += it

Then after some other code, we do:

harnesslabOnlineNodes.each {
		println 'Starting configure job for: ' + it.name
		def nodeLabel = it.name // Since each of our nodes has a label with its name. If this isn't the case for you, you can do some regex on the it.name to convert each node's name into whatever the unique label is.
                params_with_label += new org.jvnet.jenkins.plugins.nodelabelparameter.LabelParameterValue('NODE_LABEL', nodeLabel)
                def paramsAction = new hudson.model.ParametersAction(params_with_label)
                // Then other code to get the cause and job
                boolean targetBuildQueued = job.scheduleBuild(5, cause, paramsAction);

This way, we end up queueing 40 parallel jobs, each pointing at 1 node, but if we were change anything about the node configuration or number, we wouldn't need to alter any code.

Hope this helps!

Hi Josh,

Thanks for sharing your solution, I will look into it as an workaround.

I still think that no manual code or parent job should be needed and that this is an bug.

If I have a label "someLabel" that I have applied to nodeA, nodeB and nodeC.
If I enable "Run on all nodes matching this label" with the description "The job will run on all nodes matching the label" for the label "someLabel" I expect the job to run on nodeA, nodeB and nodeC.

Ah, if you want that functionality, I recommend the Matrix Project Plugin. This lets you create a job where you check off a series of labels, and it will run the build on 1 machine per label. So, for example, if you have 5 boxes, each with a unique label, and you check those 5 unique labels, it can run in parallel on those 5 boxes. The only issue with this plugin is that the list is static, and if you want to add nodes you'll have to re-configure the job.

I have solved this using a trigger job and a BuildParameterFactory as described on the wiki: https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin

It would be nice if this could be solved by only using one single jenkins job without any downstream triggering.

When using a Node parameter with multiple nodes selected it will run the job on all selected nodes and the Allow multi node selection for concurrent builds option is chosen. I would expect the same to happen for a Label parameter when checking Run on all nodes matching the label otherwise this checkbox is pretty useless since there is the Restrict where this project can be run option. Running the same job on all machines with the same label without having to add a trigger job is extremely useful, it can be used to limit test jobs to a subset of the test slaves e.g. all Windows 7 test slaves. Unfortunately the Node parameter requires much more maintenance compared to using labels.

I tried for both Node and Label parameter with all variations of settings.
The build doesn't happen on all the systems.
Is there any solution to this?

Hello Aswin,

Did you try the steps I wrote out above? The critical understanding is that any combination of nodes/labels will only run on a single machine which matches those criteria.

Good luck,
Josh

I too discovered this issue today and am disappointed that when you select run on all nodes matching this label that it only executes on 1 node...

Minimally, the confusing wording should be changed ASAP to avoid confusion to something like: run on only 1 random node that matches the label

Ideally, it should do what it states and run on all nodes that match the label.
As an improvement, supporting label regex matching would make life even easier for some