[Feature Request] Linter rule to enforce consistent API version across codebase
- Dominant language
- Bicep
- Stars
- 3.6k
- Forks
- 830
- Avg merge
- 1d 21m
- Merged PRs (30d)
- 79
Description
**Is your feature request related to a problem? Please describe.**
Currently, Bicep requires hard-coding the API version, i.e. specifying it explicitly next to each parent resource. It must be a literal string, it doesn't support a variable, e.g.:
```bicep
resource cluster 'Microsoft.ServiceFabric/clusters@2021-06-01' existing = {
// ...
}
```
This may easily lead to an inconsistency between API versions of the same resource type across different Bicep files. Moreover, nothing prevents using multiple API versions within the same file.
Note, this is not the case in regular ARM template: it supports using a variable/parameter, which may come from a single location:
```json
{
"name": "Common",
"type": "Microsoft.Resources/deployments",
"apiVersion": "[variables('deploymentApiVersion')]",
"properties": {
"mode": "Incremental",
"templateLink": {
"uri": "[parameters('template_Common')]",
"contentVersion": "1.0.0.0"
}
}
},
{
"name": "Resource1",
"type": "Microsoft.Resources/deployments",
"apiVersion": "[variables('deploymentApiVersion')]",
"properties": {
"mode": "Incremental",
"templateLink": {
"uri": "[parameters('template_Resource1')]",
"contentVersion": "1.0.0.0"
},
"parameters": {
"apiProfile": {
"value": "[reference('Common').outputs.apiProfile.value]" // a source of truth for all API versions used across the codebase
},
},
"dependsOn": [
"[resourceId('Microsoft.Resources/deployments', 'Common')]"
]
}
```
**Describe the solution you'd like**
In the leu of a solution for https://github.com/Azure/bicep/issues/10683 and an improvement towards https://github.com/Azure/bicep/issues/622, I propose a linter rule which would:
1. Either require an API version to be the same in all files in the folder (per resource type)
2. Or enforce a certain API version to be used (again, per resource type)
Contributor guide
Research direction
No implementation files, tests, or entry points are named. Start by reading the linked issues #10683 and #622, then clarify whether the rule should enforce consistency across files or a fixed version per resource type. Done means the selected policy is enforced by the linter with suitable diagnostics and coverage for the stated cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100