Skip to content

fix support default selection for prompt param #5200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix support default selection for prompt param #5200

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 30 additions & 11 deletions cli/azd/pkg/infra/provisioning/bicep/prompt.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -350,42 +350,61 @@ func (p *BicepProvider) promptForParameter(
return nil, fmt.Errorf("parameter '%s' has no allowed values defined", key)
}

// defaultOption enables running with --no-prompt, taking the default value. We use the first option as default.
defaultOption := options[0]
Copy link
Contributor

@weikanglim weikanglim May 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@weikanglim weikanglim May 16, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// user can override the default value with azd metadata
if azdMetadata.Default != nil {
if !slices.Contains(options, *azdMetadata.Default) {
return nil, fmt.Errorf(
"default value '%s' is not in the allowed values for parameter '%s'", *azdMetadata.Default, key)
}
defaultOption = *azdMetadata.Default
}

choice, err := p.console.Select(ctx, input.ConsoleOptions{
Message: msg,
Help: help,
Options: options,
Message: msg,
Help: help,
Options: options,
DefaultValue: defaultOption,
})
if err != nil {
return nil, err
}
value = (*param.AllowedValues)[choice]
} else {
var defaultValueForPrompt *string
if azdMetadata.Default != nil {
defaultValueForPrompt = azdMetadata.Default
}
switch paramType {
case provisioning.ParameterTypeBoolean:
options := []string{"False", "True"}
choice, err := p.console.Select(ctx, input.ConsoleOptions{
Message: msg,
Help: help,
Options: options,
Message: msg,
Help: help,
Options: options,
DefaultValue: defaultValueForPrompt,
})
if err != nil {
return nil, err
}
value = (options[choice] == "True")
case provisioning.ParameterTypeNumber:
userValue, err := promptWithValidation(ctx, p.console, input.ConsoleOptions{
Message: msg,
Help: help,
Message: msg,
Help: help,
DefaultValue: defaultValueForPrompt,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@weikanglim weikanglim May 16, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}, convertInt, validateValueRange(key, param.MinValue, param.MaxValue))
if err != nil {
return nil, err
}
value = userValue
case provisioning.ParameterTypeString:
userValue, err := promptWithValidation(ctx, p.console, input.ConsoleOptions{
Message: msg,
Help: help,
IsPassword: isSecuredParam,
Message: msg,
Help: help,
IsPassword: isSecuredParam,
DefaultValue: defaultValueForPrompt,
}, convertString, validateLengthRange(key, param.MinLength, param.MaxLength))
if err != nil {
return nil, err
Expand Down
Loading