fix support default selection for prompt param

[vhvb1989]

This change allows users to define a default option (or value) for input parameters and use it when AZD prompt for it.

The use case is to force users to input/select values for parameters, making them aware of the selection, but controlling what AZD should highlight as the default option during the prompt. This is different from setting a default value directly for the parameter in bicep, which would skip the prompt.

This change also enables running with --no-prompt to use the default values.

Example. For a parameter model like:

by using

@metadata({azd: {
  default: 'gpt-4.1;2025-04-14'
}})

AZD would prompt like:

And if user runs azd up --no-prompt, AZD would take the default value during the prompt automatically.

[weikanglim]

This isn't explicitly called out in the PR description, but I'm guessing we're making an intentional change to have --no-prompt always select the "first value". Is the "first value" is guaranteed to be stable across runs?

I would also admit that as a first-time user, this may not be extremely intuitive, but I could see that choosing a value may help ensure --no-prompt to work non-interactively.

[vhvb1989]

yeah, this change is trying to enable --no-prompt . The current user's feedback is: "why isn't AZD choosing the highlighted value I see during the prompt like in other prompts, like the location parameter?"

User is aware of how --no-prompt can automate the process by taking whatever selection is displayed in a list. Wondering why that's not the case when not using location parameters

[weikanglim]

I see. Thanks for sharing that perspective, I see how convenient it is for --no-prompt to skip most prompts assuming suitable defaults.

Just to double check on the initial question: does options[0] chosen here correspond to the first value declared in the allowed list?

For example, in @allowed(['foo', 'bar']), is foo always chosen? I guess if we do document it as such, it is understandable behavior, and makes --no-prompt useful for this specific purpose, so I'm in favor of doing it assuming the order is indeed preserved.

[weikanglim]

Do you happen to have examples to share for number and booleans? I'm curious how the type conversion ends up happening and what the user provided values end up looking like.

[vhvb1989]

The default field for the azd metadata is *string . This means that if you want to set a default, you must quote it as string. If you don't quote it, it is ignored and the value becomes nil.

I didn't want to update the *string to any as part of this change.

In the future, if someone ask for it, we can improve this by supporting any type and calling sprintf(%v, value) to get its string representation. But I dont think we need it now

[weikanglim]

Thanks for clarifying the behavior!

If I understand the explanation correctly, this is what we handle currently:

@metadata({
  azd: {
    default: 'True'
  }
})
param somethingElse bool

@metadata({
  azd: {
    default: '12345'
  }
})
param digit int

While a more realistic version that matches a Bicep user's expectations may be more along the lines of:

@metadata({
  azd: {
    default: true
  }
})
param somethingElse bool

@metadata({
  azd: {
    default: 12345
  }
})
param digit int

From the above, I'm wondering if we could consider defer adding support for these types, or perform the conversion to match the expected types when writing Bicep -- the bool case of 'True'/'False' isn't particularly intuitive...

The main thing is that I'd prefer is to avoid supporting the stringified version for longer term.

[weikanglim]

Nothing blocking, just left a few minor comments