Add "magic" functions/properties to generate common resource properties that don't have that property natively available
- Dominant language
- Bicep
- Stars
- 3.6k
- Forks
- 830
- Avg merge
- 1d 21m
- Merged PRs (30d)
- 79
Description
The canonical example seems to be storage accounts. Connecting to a storage account requires a connection string, but the storage RP does not have a `list*()` function for this. This means user's have to author this complex string themselves which is very error prone. For example, we see:
```bicep
value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageAccount.id, storageAccount.apiVersion).keys[0].value}'
```
Instead we should be able to provide:
```bicep
value: storageAccount.generateConnectionString()
```
There are some philosophical questions that come into play of if we *should* do this, given that the "right" fix is for storage API to make this property available natively. However, this fix has proven difficult to get prioritized, so it's leading us to consider filling the gap ourselves.
Contributor guide
Research direction
Begin with the storage-account connection-string example and the existing listKeys/API-version behavior described in the issue. Define the scope and resolution of the native-property gap versus a Bicep-level magic function; done requires an agreed design for generating common resource properties, with storage accounts as the concrete case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100