Rudder

We should just accept parameter variable, always. Of course they can break afterward, but here we are preventing valid, common usage. Validation (client side validation) should always be just an advice.

We can't either really try to wait for generation and fail there, because some variables can be only defined on agent.

So, I would say:
1/ authorize parameter in regex check
2/ if possible, for variable whose value is known at generation, add back the regex check post expansion.

Another question: how does it works for "can not be empty" variable? Of course, technicaly "${something}" is not the empty string, but its expansion may be. Do we check post expansion correctly? If not, we should (and the regex case is even more inconsistant)

Actually, boolean can't be an interpolated variable, because we translate them into checkbox in the UI, and checkbox need to know if it's true or false to display correctly. We could use a special widget that let user enter a value, but it becomes complicated and will be for an other time (I'm not even sure we want to go that way).

Work in progess here: https://github.com/fanf/rudder/commit/d9e7d1e66207b37f8137f7062a6d35c49fff2e7a

Work in progess here: https://github.com/fanf/rudder/commit/a1f2620e898be82f36a51753d35ad84c547f556e

So, to sum, we will be able to have parameter where regex or int are awaited (and string of course), but not boolean because boolean need to be known when the directive is configured to display the checkbox state (and there's no way to enter the property in all cases).

We kept the old behavior, so any ${...} is authorized (to allow cfengine/etc node side expansion), but if the variable is a rudder one (ie: ${rudder.*} or ${node.properties[...]} we DO check that the variable is ok (is defined for rudder ones, is well formed for node properties - we can't check for existence, of course, since we are in a directive, not in nodes).

The corresponding PR also change a technical backend point: the parser lib used to parse properties was switched to a new one: "fastparse".