Skip to content

Instantly share code, notes, and snippets.

Breaking change review for Go management SDK

Routine tasks

We have two routine tasks related with Go Management SDK breaking change review process:

  1. For all public/private PR for management API change, we need to approve the Go SDK breaking changes if exist. The review should be completed in around two business day. Refer: https://aka.ms/azsdk/pr-getting-help for more detail about spec review process. So, the steps are:

TCGC Client Revisit

We have many client related types, decorators and concepts in TCGC and some of them are implicit, which makes author hard to know how to generate a needed client. This doc aims to revisit all client related things in TCGC and try to have a consolidated design output.

User scenario

  1. Single level client
client = TestClient(endpoint="endpoint", credential=AzureKeyCredential("key"))
result = client.do_something()
  1. Client with sub client and sub client could only get from parent client

Requirement

In swagger, we have testmodeler to extends m4 model to help to link swagger example file to corresponding operation, as well as map example value to its type schema. When we switch to TypeSpec, we currently still use swagger example file to show the payload example of an operation. Also, TCGC is the middle model layer for TypeSpec, just like m4 for swagger. So, TCGC need to do what testmodeler do.

Basic rules

Current example/test generation way of all languages could be grouped into two kinds:

  1. Use example model in testmodeler to generate the example/test codes: Go MPG from swagger, JS HLC, .NET MPG from swagger
  2. Use self-defined example model and do example value mapping/fake value generation by language's code generator: Java, .NET DPG, Python

Request

With exact body definition

model Foo {}
op foo(@query q: string, @header h: string, @body body: Foo): void;

Service method parameters:

  • q: string
  • h: string
  • body: Foo {}
@tadelesh
tadelesh / tcgc-api-design.md
Last active May 15, 2024 06:59
TCGC versioning

Overview

TCGC common models need to support TypeSpec versioning. The support should be separated into two parts:

  1. Support to get common models from specific version/latest version. This should be applied to all TCGC APIs.
  2. Support to provide all versioning information for common models that languages' emitter could leverage to generate SDK with version resilency.

Support to get specific/latest version info for all TCGC APIs

Config

  1. A new option api-version will be added to the TCGC context and should be configed in languages' tspconfig.yaml file.
  2. If the api-version is not set or set to latest, then all returns of TCGC APIs will be the information of latest API version.
  3. If the api-version is set to a specific version, then all returns of TCGC APIs will be the information of that API version. If the version is not existed, then a diagnostic warning will be passed to emitter and will fallback to latest version.
// Generated from example definition: https://github.com/Azure/azure-rest-api-specs/tree/main/specification/compute/resource-manager/Microsoft.Compute/stable/2022-03-01/ComputeRP/examples/virtualMachineExamples/VirtualMachine_Create_LinuxVmWithPatchSettingAssessmentModeOfImageDefault.json
func ExampleVirtualMachinesClient_BeginCreateOrUpdate() {
cred, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil {
log.Fatalf("failed to obtain a credential: %v", err)
}
ctx := context.Background()
client, err := armcompute.NewVirtualMachinesClient("{subscription-id}", cred, nil)
if err != nil {
log.Fatalf("failed to create client: %v", err)