Added tools for generate-sdk and build-sdk

[raych1]

Overview:

• generate-sdk: run tsp-client command directly
• build-sdk: shell out to run language-specific script

Work items:
#11403
#11402

Design spec

Generate tool:

in spec repo context

in sdk repo context

Build tool:

using inline command

using dedicated build script

[Copilot]

Pull Request Overview

This PR adds two new SDK management tools to the Azure SDK CLI: generate-sdk and build-sdk. The generate tool allows running TypeSpec client generator commands to create SDK code from tspconfig.yaml or tsp-location.yaml configuration files, while the build tool executes language-specific build scripts for SDK projects.

• Adds SdkCodeTool class implementing both SDK generation and build functionality
• Integrates the new tool into the CLI by registering it in SharedOptions
• Provides comprehensive test coverage for the new functionality

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
SdkCodeTool.cs	Core implementation of SDK generation and build tools with TypeSpec client integration
SharedOptions.cs	Registers the new SdkCodeTool with the CLI framework
SdkCodeToolTests.cs	Comprehensive unit tests covering both success and failure scenarios

[haolingdong-msft]

Thanks for the PR! Could you share some screenshots to show how the tools are invoked in agent scenarios?

[raych1]

Thanks for the PR! Could you share some screenshots to show how the tools are invoked in agent scenarios?

@haolingdong-msft Here're some screenshots FYI. Feel free to get my branch and try locally, let me know if there're any feedback. This is another PR](#11868) of the instructions change.

Generation from spec repo
This one takes a few steps before 'generation way' selection. We might optimize the prompts and instructions to make this simpler. CC: @praveenkuttappan @maririos

Generation from sdk repo

input and output

Building code from sdk repo

[haolingdong-msft]

Hey @raych1, for defining inline command, may I know why should we still have path and set it to "". Can we remove path, and keep command only?

[raych1]

may I know why should we still have path and set it to "". Can we remove path, and keep command only?

@haolingdong-msft yes, we could since we don't validate the content against schema.

[haolingdong-msft]

Thanks for the PR! Mostly looks good to me. Approve to unblock merge. We can validate and test after merge. And improve from here.

Note on this comment: the name swagger_to_sdk_config.json is a bit strange to me. swagger is legacy and deprecating now, do we want to use typespec_to_sdk_config.json?

[raych1]

the name swagger_to_sdk_config.json is a bit strange to me. swagger is legacy and deprecating now, do we want to use typespec_to_sdk_config.json?

Naming change for an existed file is not trivial, which involves adding new name, keeping both names working for a period of time, migrating all the dependent tools to use the new names, deleting the old name. There're several places in current toolsets which still uses 'swagger'. We might consider renaming them across all these places sometime in the future.

[raych1]

@raych1 can we get all languages to confirm that this works for them for both management plane and data plane before this PR gets merged?

@maririos I validated all five languages both mp and dp, SDK code can be generated. For buildSDK, it works well too except Go(its script isn't ready yet) and python(without compile).