[Epic] Onboard Rust to SDK Validation Pipeline in Spec Repos

[raych1]

Rust Onboarding

Goal

Enable the SDK validation pipeline in the spec repos (azure/azure-rest-api-specs and azure/azure-rest-api-specs-pr) to generate, build, and pack Rust SDK packages from TypeSpec definitions using azsdk-cli. This includes adding Rust support to the CLI tooling (verify setup, pkg build, pkg pack), integrating azsdk-cli into the spec-gen-sdk-runner orchestration layer, and wiring up the pipeline YAML to run the end-to-end flow for Rust.

Task Breakdown

azsdk-cli changes (azure-sdk-tools repo)

#	Task	Description
0	azsdk verify setup — Rust support	Add Rust environment validation/installation: rustup, cargo, required toolchain version, cargo extensions (e.g. cargo-fmt, cargo-clippy). Pipeline calls azsdk verify setup --language rust instead of manual scripting.
1	azsdk pkg build — Rust support	Implement Rust build logic in azsdk-cli (invoke cargo build with correct flags/workspace config). Or shell out to run an existed build script in Rust repo.
2	azsdk pkg pack — Rust support	Implement Rust packaging logic in azsdk-cli (invoke cargo package to produce distributable artifacts). Or shell out to run an existed build script in Rust repo.

Note: azsdk pkg generate already supports Rust — it invokes tsp-client under the hood, so no generate-side changes are needed in azsdk-cli.

Note: The verify setup or build/pack steps may require a configuration file or script in the azure-sdk-for-rust repo to define prerequisite installation details (e.g., toolchain version, workspace layout). Exact requirements will be determined during implementation.

spec-gen-sdk-runner migration work required for Rust onboarding (azure-rest-api-specs repo)

The spec-gen-sdk-runner is the pipeline orchestration layer that detects changed specs, invokes SDK generation, and aggregates results. Today it shells out to spec-gen-sdk (TypeScript/npx). The tasks below are mostly generic runner migration work required to onboard Rust: they replace the inner call with azsdk-cli for TypeSpec specs, add emitter pre-checks, build command construction for generate/build/pack, capture JSON responses, and translate azsdk-cli output into the ExecutionReport format already used by downstream pipeline steps.

#	Task	Description
3	Rust language key mapping	Add azure-sdk-for-rust → "rust" mapping in emitter check and adapter.
4	Emitter-enabled check (emitter-check.ts)	Run typespec-metadata emitter, check if "rust" exists in metadata.languages, extract packageName/outputDir.
5	ExecutionReport adapter (azsdk-adapter.ts)	Build ExecutionReport from azsdk-cli generate/build/pack JSON responses + typespec-metadata output.
6	OpenAPI vs TypeSpec decision gate	Rust is TypeSpec-only, so always routes to azsdk-cli path (no spec-gen-sdk fallback).
7	Command construction (command-helpers.ts)	Build command arrays for azsdk pkg generate, azsdk pkg build, azsdk pkg pack.
8	Command execution (utils.ts)	Generalize to capture stdout JSON for azsdk-cli commands.
9	Integration into command flow (commands.ts)	Wire emitter check → generate → build → pack → adapter into generation flow.
10	Unit & integration tests	Tests for emitter check, adapter, command construction, routing, end-to-end mock.

Pipeline definitions and AzDO setup

#	Task	Description
11	Pipeline YAML	Add install-azsdk-cli.yml step; use azsdk verify setup --language rust for Rust toolchain setup.
12	Create Rust SDK validation pipelines	Create new pipeline definitions for Rust in both azure/azure-rest-api-specs and azure/azure-rest-api-specs-pr repos.

Validation & rollout

#	Task	Description
13	End-to-end validation	Test with a real TypeSpec-defined Rust SDK package in the pipeline.
14	Rollout	Phase 1: enable Rust validation in the spec repos as non-blocking so failures do not prevent PR merge, and monitor run quality/stability. Phase 2: after the signal is trusted, flip the pipeline/check settings to required so Rust validation blocks PR merge on failure.

[heaths]

I'm already working on most of this for azsdk tracked here: Azure/azure-sdk-for-rust#3621. As I've explained to @maririos, I don't really want to duplicate our build commands, test authoring, validation, etc., into a centralized location that's harder to maintain when we already have agent instructions and skills in our repo that we've been using with Copilot (CLI, VSCode, and GitHub all) that work. And as we improve those, relying solely on instructions in our repo that we can update with immediate effect makes far more sense.