BICEP news and updates

Bicep Community call February, 23 –

March 1^st release version incorporates following feature –

CIDR math functions

BICEP public registry completions –

Nullable types can be thought of as parameters that are optional, but without a default value. Previously, in order to validate whether a user-supplied string was null or not, we would initialize the parameter as a string with an empty value, like this: "Param storageAccountName string = ''". However, with nullable types, we can now simply use a question mark to indicate that the parameter is optional: "Param storageAccountName string?". This approach has the added benefit of providing an implicit default value of null.

In the screenshot from the Bicep community, a module is passing the parameter value "sa" to storageAccountName, indicating that it should deploy an account with that name. However, the construct and validation process is much simpler with nullable types, as we don't need to explicitly check for null values.

In Bicep version 15 or higher, instead of using the "?" operator for the parameter value (if viewed as a key-value operator), we can use "?" at the end of the data type. This means that we can indicate that a parameter is nullable by adding a question mark at the end of its data type, rather than using the "?" operator in the parameter value.

To report a bug related to Kubernetes in Bicep extensibility providers, you need to enable the experimental feature for Bicep in Visual Studio (VS) or Visual Studio Insider code. Then, you should enable registry reference completions to help with reporting the bug in the Bicep extensibility Kubernetes providers.

After enabling the feature below, you can use module reference auto-complete with aliases and get access to the public registry. The "br" alias refers to the Bicep registry. Note that for private registries, the auto-complete feature may not populate all references or show the reference page directly, but this will be addressed in a future release.

Bicep rules include the following updates:

V1.24: Added support for Bicep lambda functions and fixes for policy-as-rules.

V1.25: Added configurable Bicep CLI version (to avoid confusion with Azure CLI versions), support for Bicep custom types, and support for Bicep to Object function.

To test Bicep with over 350 built-in rules for Azure resources, you can install the PS Rule extension and use the "Cntl+sh+p" and "psrule analysis" commands. This will show all security vulnerabilities based on Azure Policy (CAF/WAF). See the following GitHub repository for more information: https://github.com/microsoft/PSRule.Rules.CAF

The "tests" file displays anything that could inherit from the main.bicep file.