|
|
|
[
Permlink
| « Hide
]
Robin Shen [16/Jan/16 03:11 AM]
Can you please explain more about "native node filtering feature" for variable prompt selector? Or with an usage scenario?
The idea here was to have something along the lines of the 'Prompt as configuration picker', but for available nodes. The options for this 'Prompt as node picker' would be the same as the 'Node Selection' dropdown box on a build step, but would by default return all nodes in the grid.
This is something I'm having to do via script with unfortunate frequency and I figured it would be much nicer this way, especially since the majority of the code already exists elsewhere in QB. Hopefully that's a bit clearer. Understand, will add this in next one or two patch releases.
We investigated this further and it turns out that you can define a variable say "nodes" in root configuration with below value:
${groovy: def nodes = ""; for (node in grid.allNodes) nodes += "," + node.address; return nodes; } And then for whatever variable you want to prompt the node addresses, just define the "choices" value in "prompt as selection box" as: ${vars.getValue("nodes")} This is a much flexible approach and can avoid repetition works.
Aye, this is what I am doing currently, but it's not nearly as nice as the node selector functionality (especially when it comes to filtering nodes by platform or resource). Sure, I can add that filtering to the scripts, but now we're talking about having a variable per platform/resource I want to filter nodes by.
Would a patch adding this functionality be accepted, or is it a dead issue from your perspective? We do not plan to add this as it seems odd to only add this special choice to the variable prompting considering other options are very general (prompt as input box, prompt as selection box, etc.) We do not want to complicate the UI when there is a workable approach available.
Yes you are right, we actually should not add that either. We add that in order to satisfy requirement of some other customer but it turns out that it is not sufficient as that customer also want to filter against the configurations which is not easy to cover in the prompt setting. So they eventually write the script themselves to achieve their flexibility. And this special prompting type leaves there in case some one has used it. You also has the requirement of filtering the node by resource/platform (and other customers may have other filtering requirement for instance by cloud profile, etc.), so putting it into a standard prompt type is not a good approach from our points of view.
|