Request for better Parameter validation

[richardissimo]

There's a great article covering Parameters in Bicep which (at the time of writing) covers how decorators can be used to specify constraints for things like minLength and maxLength, to defend against invalid values.

Maybe it's just me; but most of the things that I'm having to declare as parameters are the names of things. Whenever I am entering a name through the portal, if I enter something which breaks the rules, it pops up a little warning, typically saying something like:

The value must match the expression '^[A-Za-z0-9]$|^[A-Za-z0-9][\w-./~]*[A-Za-z0-9]$'.

So my initial thought was that it would be really nice if there was a Regex-style decorator that I could use to validate against that definition. And to be fair, that might be a useful addition to have anyway. But then I thought about it... there are loads of different naming rules, for different things; and (if I can be honest), I really don't want my bicep scripts to contain the actual definitions of the naming rules - aside from anything else, they would potentially get out of date, and I would have to trawl through the files updating all the Regexes.

What I'd really like is to be able to reference a naming rule by referring to a versioned resource type, for example, like where I might refer to a resource being of type 'Microsoft.ServiceBus/namespaces@2022-01-01-preview'. Then if I've got a parameter which represents a name for a particular type of resource, I can add a decorator which will enforce the same name validation as the Azure portal would, without me even needing to know or care what that validation was.

For example:

@description('Name of the Service Bus namespace')  
@nameValidation('Microsoft.ServiceBus/namespaces@2022-01-01-preview')  
param serviceBusNamespaceName string

And the Regex validator would probably be nice as well, albeit completely separate from this :).

[jeskew]

Work on this feature is being tracked in #9229. Regular expression validators are also being worked on (tracked in #8409).

[richardissimo]

Thanks @jeskew, it's good to see the Regex validator has been independently requested in #8409, so I can forget about that.

I'll take a look at #9229.