parameters.md

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

1. 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.
2. thisMustBeFoo and isFooFoo 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.

This looks like a good solution that is presumably low cost. Does that sound right to you @anthony-c-martin? If so, I think we should get this prioritized sooner rather than later. Also, is there a reason this is marked as secret? I'd like to add this context to Azure/bicep#10777

@alex-frankel no reason - I've made it public.