Imagine the following Bicep file:
@allowed(['foo'])
param thisMustBeFoo string
param isFooFoo bool
With the following parameters file:
using 'main.bicep'
param thisMustBeFoo = 'foo'
param isFooFoo = (thisMustBeFoo == 'foo')
This works great - if the user changes thisMustBeFoo
to 'bar'
, they get an error and the deployment will not be attempted.
Now imagine the user supplies the following deployment command and overrides "thisMustBeFoo":
az deployment group create --parameters 'main.bicepparam' --parameter thisMustBeFoo='bar'
Here the values supplied to ARM will be:
thisMustBeFoo: 'bar'
isFooFoo: true
- Bicep is now unable to do any sort of deep type validation, and instead has to rely on ARM to catch the error. In this case, it's trivial, but in cases where the value is being passed to an RP, it could easily cause problems.
thisMustBeFoo
andisFooFoo
are clearly out of sync.
Compare this to the following:
using 'main.bicep'
param thisMustBeFoo = readEnvVar('MIGHT_BE_FOO')
param isFooFoo = (thisMustBeFoo == 'foo')
With CLI command:
export MIGHT_BE_FOO='bar'
az deployment group create --parameters 'main.bicepparam'
Now Bicep will fail the build, because it understands the value of thisMustBeFoo
at build time. There's no way the deployment will be submitted to ARM, and there's no way the two parameters can go out of sync.
Bicep Deploy solves a similar problem in a different manner. My concern is that if we release a feature with weak validation, we'll never be able to remove it.
Possible solution: AzCLI/AzPwsh pass the overridden parameter values down to Bicep CLI:
bicep build-parameters main.bicepparam --parameter thisMustBeFoo='bar'
param thisMustBeFoo = 'bar'