You were relying in the existence of a bug. There is nothing to fix in the plugin but in your configuration.

I have replied on my own ticket, but would just like to say, is changing the main behaviour of this plugin after it working one way for three/four years not rather drastic?

I am one of the users who complained that the plug-in was not doing what was originally intended and what the documentation clearly stated it would do. I applaud that the bug was corrected. If a plug-in states that when the ALL option is specific it should execute on all servers matching a label. If it don't then it's broke...

We began to use the "fixed" version in our environment now that it work as advertised.

By the way, this plug-in helps us execute jobs on all hosts matching a label w/o having to memorize "lists" of targets supporting specific features... Makes adding/deleted slaves to a feature much easier!

Eric L. Edberg

My slaves are all identical and so is the job they run, I just run another Jenkins job with a for loop in it which triggered another job which was set to run on all, this would spawn out the jobs as many times as it needed to slaves... it was quite a nice way to control running the same job with different parameters across a load of slaves... I didn't see this 22185 as a bug, I just wrote code to make the plugin do what I wanted.

I agree with the fix for the reasons ericledberg noted. Before the patch I created a Pipeline job intending to rely on the documented functionality of the label, "broadcasting" execution to every node with the label expression but then had to write a bunch of extra Jenkins API logic to discover the matching nodes. Ie the target node pool is constructed automatically, but I had to write unnecessary (IMO) logic to do so. Plus explicitly specify the parallel execution when the pipeline script should have been a 1- to 2-liner at most.