We need to expose the customDomainVerificationId property for web/mgmt/web. It's a property already returned by the REST API, the go-sdk is just not exposing it in the SiteProperties struct. This is for use in the azurerm_app_service terraform resource, being tracked by https://github.com/terraform-providers/terraform-provider-azurerm/issues/7537 to enable automatic custom domain verification for app services.
type SiteProperties struct {
// Add these 2 lines â–¼
// CustomDomainVerificationId - READ-ONLY; Custom domain verification id used in the txt record of custom domains to verify them for use on a app service.
props.CustomDomainVerificationId *string `json:"customDomainVerificationId,omitempty"`
}
In this file (for each maintained version):
This is the reference in the azure-rest-api-specs:
"customDomainVerificationId": {
"description": "Unique identifier that verifies the custom domains assigned to the app. Customer will add this id to a txt record for verification.",
"type": "string"
}
Although looks like its only in 2020-06-01, not 2019-08-01, the latest version you currently use...
Hi @AdamCoulterOz thanks for this issue!
But unfortunately we cannot backport this new property in 2020-06-01 to 2019-08-01 if it is not in 2019-08-01's swagger.
To solve this, we will release the new api-version of 2020-06-01 for the web RP in the next minor release.
@ArcturusZhang It is present in the actual older rest api version, just not in the swagger definition. Is that normal?
When is the next minor release scheduled?
Hi @AdamCoulterOz sometimes this happens. But it is unlikely to backport it to the old api-version since per our policy, adding new property in response is a breaking change to the swagger definition - which is something that the service team would try to avoid.
The next minor version should be released no later than next Wednesday
Hi @AdamCoulterOz new minor version v45.1.0 has been released with this property added to 2020-06-01 api-version: https://github.com/Azure/azure-sdk-for-go/blob/d63896ea550a156efe80237d344930c856222427/services/web/mgmt/2020-06-01/web/models.go#L22234
Therefore I will close this issue. If you still have questions, please feel free to commend and/or reopen this issue, thanks
@ArcturusZhang thanks for this!! :-)
@ArcturusZhang
But it is unlikely to backport it to the old api-version since per our policy, adding new property in response is a breaking change to the swagger definition - which is something that the service team would try to avoid.
Surely if the Swagger doesn't match the API definition (e.g. it's always been incorrect) - adding a missing readonly field to the response can't be a breaking change? As such technically this field could be backported to those older API versions without being a breaking change - since unlike a new field in the Request (which /would/ be a breaking change if it's Required, but isn't as an Optional field), a new Response-time field (particularly one that's read only) won't be a breaking change?
Hi @tombuildsstuff
Yes, adding a readonly field to the response is not considered as a breaking change. It may be possible to back-port to old api-version if the service team make it readonly in the old api-version
Most helpful comment
Hi @AdamCoulterOz sometimes this happens. But it is unlikely to backport it to the old api-version since per our policy, adding new property in response is a breaking change to the swagger definition - which is something that the service team would try to avoid.
The next minor version should be released no later than next Wednesday