We have a situation as follows: we have a single Jenkins job which may be executed on agents with 3 different configurations on them. These agents are filtered by a set of labels, something like this:

configuration 1 -> label1&&label2&&label3
configuration 2 -> label4&&label5&&label6
configuration 3 -> label7&&label8&&label9

This allows us to define labels on each of our agents describing their configurations, and allows us to map combinations of those labels to specific values for reference. Further, we want to allow users to trigger a build of this job and allow them to select which of the 3 supported configurations they want to run with. Depending on which configuration they choose we want the build to be restricted to only those agents with the label expressions found on the mapping I've illustrated above.

Currently the only way I know of to customize the build location dynamically like this is by using the node label parameter plugin. Further, this plugin only supports 2 parameter types: node and label. The node parameter does allow you to select a list of allowed nodes from the list of available nodes, but unfortunately labels are not presented there so this option won't meet our needs. The label parameter does allow one to define arbitrary label expressions to target specific agents, and you can enter the filters I mentioned above in that field to target the correct locations, however this presents a usability problem because users need to know what the supported / valid filter expressions are for each configuration which is fragile at best.

What I'd like to see is some way to define a list of supported label expressions in some way. One possible solution I could see might be to support variable name expansion within the build label field. Then we could define a 'Choice' parameter with a drop-down list of supported filter patterns the user could choose, which would then be expanded by the label expression (ie: ${selected_label_filter}). Another alternative might be to provide an additional option to the 'label' parameter which can take a list of supported filter expressions, much the same way the Choice parameter works, directly injecting the filter expressions based on the user's selection. Maybe there's some other way to achieve similar results. Feel free to suggest alternatives.