Azure / Azure/bicep-registry-modules
[AVM CI Environment Issue]: UDT/RDT test shows incorrect warning for discrimnated types
- Dominant language
- Bicep
- Stars
- 737
- Forks
- 564
- Avg merge
- 3d 15h
- Merged PRs (30d)
- 30
Description
### Check for previous/existing GitHub issues
- [x] I have checked for previous/existing GitHub issues
### Issue Type?
Bug
### Description
With the current version of Bicep, the JSON template is rendered a bit differently and the check for UDTs/RDTs does not account for said way.
You can see the result [here](https://github.com/Azure/bicep-registry-modules/actions/runs/27914529778). The parameter **does** have a type and should now show up as incorrect.
The reason for the warnings that the check in the corresponding test
https://github.com/Azure/bicep-registry-modules/blob/7fb8f74c44b2f12b511b6429cbd72d6c84f748e3/utilities/pipelines/staticValidation/compliance/module.tests.ps1#L1075-L1077
Assumes that the parameter has a key `$ref` for UDTs (which is the way it used to be). However, at least in the latest version of bicep, the parameter (when debugging the right after the aforementioned lines shows the parameter as
```json
{
"type": "object",
"discriminator": {
"propertyName": "kind",
"mapping": {
"Automatic": {
"$ref": "#/definitions/resourcePredictionsProfileAutomaticType"
},
"Manual": {
"$ref": "#/definitions/resourcePredictionsProfileManualType"
}
}
},
"nullable": true,
"metadata": {
"description": "Optional. Determines how the stand-by scheme should be provided."
},
"name": "resourcePredictionsProfile"
}
```
So now, there's a `discriminator` key with a `mapping` in it per each case. Each of those then must have a `$ref` or have a metadata key with the value `__bicep_resource_derived_type!`.
To test the last point, I expanded the type `resourcePredictionsProfile` like this to debug how it would look like for a `resourceInput` value.
```bicep
resourcePredictionsProfile: (
| resourcePredictionsProfileAutomaticType
| resourcePredictionsProfileManualType
| resourceInput<'Microsoft.DevOpsInfrastructure/pools@2025-09-20'>.properties.agentProfile)?
```
Again, using the debugger, the previous JSON now looks like
```json
{
"type": "object",
"discriminator": {
"propertyName": "kind",
"mapping": {
"Automatic": {
"$ref": "#/definitions/resourcePredictionsProfileAutomaticType"
},
"Manual": {
"$ref": "#/definitions/resourcePredictionsProfileManualType"
},
"Stateful": {
"type": "object",
"metadata": {
"__bicep_resource_derived_type!": "System.Management.Automation.OrderedHashtable"
}
},
"Stateless": {
"type": "object",
"metadata": {
"__bicep_resource_derived_type!": "System.Management.Automation.OrderedHashtable"
}
}
}
},
"nullable": true,
"metadata": {
"description": "Optional. Determines how the stand-by scheme should be provided."
},
"name": "resourcePredictionsProfile"
}
```
So the test must be updated accordingly. The above should be enough information to do so.
Contributor guide
Research direction
Start in utilities/pipelines/staticValidation/compliance/module.tests.ps1 around lines 1075-1077 and inspect how the UDT/RDT parameter warning check reads the rendered JSON. Compare it with the examples in this issue, then update the check so discriminator mappings are handled and run the corresponding static validation test to confirm valid typed parameters no longer produce warnings.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- powershell
- Domain
- ci-cd, testing-qa
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100