Template assertion

[stan-sz]

Is your feature request related to a problem? Please describe.
Let the template have the ability to assert certain conditions with and fail the deployment with a meaningful (user-provided) message if the conditions are not met.

Example:

We have a script-based Azure resource provisioning that we want to rewrite to 100% Bicep. The new template takes as a param a string input (the command line to script, for back-compat). After some string manipulations (split, filter out values) we'd like to assert that the remaining values are what we expect (strings not null, etc.) before any resources get deployed to avoid:

• garbage names in to-be-created resources
• bogus RP error messages about bad input

Describe the solution you'd like
At the syntax level it could be as simple as:

assert(condition, message)

Behind the scenes this could be a new Microsoft.Resources/assert RP that the above call transpile to.

Context

This is moderately related to #1343

[MarcusFelling]

• garbage names in to-be-created resources
• bogus RP error messages about bad input

I'm wondering if we could extend param decorators to attach more constraints that would help avoid bad inputs and adhere to desired naming conventions. I'm thinking of functions to check for certain casing, characters, or strings. Do you think that would be helpful?

For more advanced assertions I could see using queries like the config-analyzer does, for the assert conditions, but runs on the templates before it's deployed.

e.g.
"query": "type == `Microsoft.Storage/storageAccounts` && properties.networkAcls.defaultAction == `Allow`"

[stan-sz]

There are cases where the inputs can be computed in the template (see #2251 (comment)). I was thinking about asserting the values of variables that hold the computed inputs.

[NeilMacMullen]

As @stan-sz says, I think it is important to be able to test a variable against constraints since params are often combined during a script. For debugging purposes, it would be valuable to be able to test a variable at any point. I.e., assuming that "known types" are introduced (#2481) it would be desirable to be able to write something like...

assert_type_constraints(Blob.Container.Name,my_blob_name)
(where Blob.Container.Name is a "known" constraint set for blob container names, derived automatically from the Azure schema)

[michael-crawford]

I just opened issue #8448, and then found this issue while searching for a workaround.

The issue referenced limits use of @Allowed to restrict the set of location values, when the param default is set to a resourceGroup().location. So, until this is supported, I have this:

@description('Location (Region) Name')
//@allowed([
//  'eastus'
//  'eastus2'
//  'westus'
//  'westus2'
//  'centralus'
//])
param locationName string = resourceGroup().location // Currently can't use @allowed with this default expression

But, I'd still like a way to limit what alternative locations are allowed, and was trying to think of a way to fail the template if the locationName parameter after evaluation was not in the set I want. While this need would go away if issue #8448 is fixed, I agree with commenters above, that some way to assert a var or param value is within an allowed set of values, or matching a RegEx pattern, or fail with an error is needed to increase robustness.