You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In cases where a template is validated before runtime and contains ARM functions cannot be evaluated (i.e. in an editor as opposed to at deployment), I believe the expectation would be that validation for allowedValues or other constraints would be ignored.
Say I want the default value of this parameter to be the last three letters of the resource group to which it is deployed. This generates a validation failure. It also generates a validation failure if the value for defaultValue is added to the array of allowedValues. Oddly with a reference to Front Door (but I think that is a known issue with template validation messages). Admittedly this is a silly example that does not seem to work as hoped any way, but it illustrates the issue.
At any rate, I would expect that neither would fail in the editor.
I think it would also be reasonable to skip validation for all parameters with defaultValue values that contain any functions (not just functions that cannot be evaluated before deployment time). Seems like lots of work for an edge case with low return any way.
The text was updated successfully, but these errors were encountered:
In cases where a template is validated before runtime and contains ARM functions cannot be evaluated (i.e. in an editor as opposed to at deployment), I believe the expectation would be that validation for allowedValues or other constraints would be ignored.
Example:
Say I want the default value of this parameter to be the last three letters of the resource group to which it is deployed. This generates a validation failure. It also generates a validation failure if the value for defaultValue is added to the array of allowedValues. Oddly with a reference to Front Door (but I think that is a known issue with template validation messages). Admittedly this is a silly example that does not seem to work as hoped any way, but it illustrates the issue.
At any rate, I would expect that neither would fail in the editor.
I think it would also be reasonable to skip validation for all parameters with defaultValue values that contain any functions (not just functions that cannot be evaluated before deployment time). Seems like lots of work for an edge case with low return any way.
The text was updated successfully, but these errors were encountered: