Azure-sdk-for-go: App Service - Expose additional existing property: customDomainVerificationId

Created on 5 Aug 2020  Â·  8Comments  Â·  Source: Azure/azure-sdk-for-go

Service Package Request

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):

https://github.com/Azure/azure-sdk-for-go/blob/f83744196dcfdff5667240eb855a76764ce3eb46/services/web/mgmt/2019-08-01/web/models.go#L19905-L19911

Web Apps customer-reported feature-request

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

All 8 comments

This is the reference in the azure-rest-api-specs:

https://github.com/Azure/azure-rest-api-specs/blob/503110cc867b221d5020fb3c50bc49b19f26f6d3/specification/web/resource-manager/Microsoft.Web/stable/2020-06-01/CommonDefinitions.json#L1832-L1835

"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

Was this page helpful?
0 / 5 - 0 ratings