-
Notifications
You must be signed in to change notification settings - Fork 218
Prompt for resources with optional resourceType #4535
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.
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
base: main
Are you sure you want to change the base?
Conversation
Alternatively, maybe instead of a |
Within a template - hence only checking during parameter processing - prompting for *any* resource is practically useless. You have to know the type to use as intended e.g., an Azure Monitor resource. To even use an existing resource in `reference()` or `resourceId()` functions you need to know the type, as do you in an `existing` resource template in Bicep.
I decided to make That would be one problem with a general |
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
@vhvb1989 you folks still interested in this one? |
if len(resources) == 0 { | ||
return "", nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should return an error. Since the intention of the method is to prompt, the fact of an empty list is a blocker to do the prompting, so it should return an error to the caller and report that there's no resources to prompt for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, my main thought with separating optional out was to also allow more permutations for other selector types. I've seen some APIs that have things like foo
, fooOptional
, bar
, barOptional
, etc., and the maintenance of and UX for all those is cumbersome. I like to separate "dials".
options := azapi.ListResourcesOptions{ | ||
ResourceType: resourceType, | ||
} | ||
resources, err := p.resourceService.ListResources(ctx, p.env.GetSubscriptionId(), &options) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I was implementing #4943, I realized that this listing would list resources in the subscription, in which case returning just the resource Name
isn't enough to fully qualify the resource ID.
Returning resource ID is obviously more powerful, and still portable, but the Bicep referencing logic is rather messy. There isn't first-party functions that support this, so it ends up being a lot of string splitting with known indexing. An example of working code that is quite unappealing can be found here.
As @JeffreyCA kindly noted, this may be simpler when Bicep supports dedicated function parsing for resource IDs.
All this is to say that our hands are a little tied on making a nice little prompt experience here, and I'm honestly not sure which way we want to lean, but I did end up returning resource ID in #4943 because subscription-scope resources were a requirement there.
Resolves #4530