-
Notifications
You must be signed in to change notification settings - Fork 748
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Template assertion #2405
Comments
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. |
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. |
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...
|
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:
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. |
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:
Describe the solution you'd like
At the syntax level it could be as simple as:
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
The text was updated successfully, but these errors were encountered: