Prompt for resources with optional resourceType#4535
Prompt for resources with optional resourceType#4535heaths wants to merge 4 commits intoAzure:mainfrom
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.
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.
There was a problem hiding this comment.
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.
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.
|
Hi @@heaths. Thank you for your interest in helping to improve the Azure Developer CLI experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days. |
|
Hi @@heaths. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass. |
Resolves #4530