[Feature] Update azd templates to use bicepparam instead of parameters.json

[jongio]

Bicep and azd now support bicepparam. Let's get the templates we own updated to use bicepparam.

https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameter-files?tabs=Bicep

[savannahostrowski]

We should also do this for simplified init too - @rajeshkamal5050 @weikanglim @ellismg

[vhvb1989]

There are some todo-templates which are not compatible with .bicepparams @jongio

For example, the SQL Server templates b/c the template uses azd to auto-generate a secrets like: https://github.com/Azure-Samples/todo-csharp-sql/blob/main/infra/main.parameters.json#L18

We don't have an alternative on bicepparam world for extending/controlling parameters the same way we do on parameters.json

[v-xuto]

@jongio Any ideas about Victor's comment?

[jongio]

Victor Is something stopping us from implementing that in bicepparam?

[vhvb1989]

Victor Is something stopping us from implementing that in bicepparam?

I little bit @jongio. The bicep-compilation flow changes; for example, if there's a parameter foo (with no default value) defined in main.bicep and you don't set a mapping to assign a value for it in main.bicepparam, bicep would return an error while compiling, like:

Before bicepparam flow, bicep would only care about compiling a template (ignoring the inputs for the parameter definitions). That allows azd to take control after bicep compilation to inspect the parameter definitions and ensure getting a value for each of them.

With bicepparam, we need to think and define some strategy for azd to help getting the input values... Some alternatives are:

• Before compiling bicep, azd gets the bicep module referenced by the bicepparam and compiles the module alone to get the parameter-definitions. Then azd parses the bicepparam and discover any missing input-values. At that point, azd can do what it knows already and prompt for values, save for the future, etc. Then, azd needs to create a new bicepparam file adding the missing values and finally call bicep compile to continue the flow. The downside is that the bicepparam from the user can't work w/o azd... so there's a big coupling for azd to actually make the infra files to work...
• Another option is to make azd to react after compilation errors. Parse the error message and fix the issue. For example, on missing parameter values, azd would ask the user if they want to fix the bicepparam by addding the missing definitions and assign values to it. The original bicepparam file would be updated. This approach removes the coupling to azd, but also is limited to fix the errors but can't make azd to apply/do special instructions defined within the bicepparam file (like it does with the directives in parameters.json).
• One final strategy is to support parameters.json together with bicepparam. In this case, the parameters.json would be azd-specific. Azd would first combine the bicepparam and the parameters.json into one single bicepparam for deployment.

@ellismg , what do you think,... do you like any of these proposals? or do you have some other idea?

[jongio]

We could also work with bicep team to update bicep to allow us to do what we need to do.

[v-xuto]

@rajeshkamal5050 Can you help contact the Bicep team to develop function auto-generate secrets (like function in json)?

[rajeshkamal5050]

@rajeshkamal5050 Can you help contact the Bicep team to develop function auto-generate secrets (like function in json)?

@vhvb1989 can you take a look and file specific asks on Bicep team w.r.t secretOrRandomPassword or such similar functions POV. Moving it to Backlog.

Note:

• Azd CLI as such supports bicepparam.
• This issue is only moving Azd templates to also use bicepparam.

[heaths]

Rather than add any azd-specific functionality that would require more implementation from both teams, why not a flag you can pass bicep that just translate what they already support to something you already support:

• readEnvironmentVariable('FOO') -> ${FOO}
• readEnvironmentVarialbe('BAR', 'baz') -> ${BAR=baz}

Adding a flag to bicep that would do this is probably more palatable than adding azd-specific functionality and its certainly more portable. Then all azd has to do is pass this new flag and you get back a JSON stream that you already support.

[heaths]

BTW: no need to save this to a file on disk - nor the main.bicep file. Maybe it was added later, but bicep build and bicep build-params has a --stdout flag so you can just unmarshal from os.Stdout and not have to worry about cleaning up temp file copies. /cc @ellismg @vhvb1989