Sync eng/common directory with azure-sdk-tools for PR 11868 (#6746)
* added instructions for sdk local workflow * fix case * Added missing comma * Update eng/common/instructions/azsdk-tools/local-sdk-workflow.instructions.md Co-authored-by: Mariana Rios Flores <mariari@microsoft.com> * Update eng/common/instructions/azsdk-tools/local-sdk-workflow.instructions.md Co-authored-by: Mariana Rios Flores <mariari@microsoft.com> * Update eng/common/instructions/azsdk-tools/local-sdk-workflow.instructions.md Co-authored-by: Mariana Rios Flores <mariari@microsoft.com> * Update eng/common/instructions/azsdk-tools/local-sdk-workflow.instructions.md Co-authored-by: Mariana Rios Flores <mariari@microsoft.com> * Replace 'tspconfigPath' by the literal file name * Added routing step to choose workflow * Added goal and action to some steps properly * Specified mcp tool name explicitly * Added back step to choose sdk generation approach * Specified the mcp tool names explicitly * Update eng/common/instructions/azsdk-tools/local-sdk-workflow.instructions.md Co-authored-by: Mariana Rios Flores <mariari@microsoft.com> --------- Co-authored-by: ray chen <raychen@microsoft.com> Co-authored-by: Mariana Rios Flores <mariari@microsoft.com>
This commit is contained in:
Azure SDK Bot
GitHub
parent
efcdeeb685
commit
871d322ea6
@ -1,32 +0,0 @@
|
||||
Your goal is to help guide the user to create SDK locally for TypeSpec changes. This is currently supported for **Python** only. User can generate SDK for other languages using SDK generation pipeline.
|
||||
## Steps to create Python SDK locally from TypeSpec
|
||||
### Step 1: Check for existing azure-sdk-for-python repository
|
||||
- Prompt the user to provide the path to their cloned azure-sdk-for-python repository.
|
||||
### Step 2: Validate repository path
|
||||
- If the user provides a path to the azure-sdk-for-python repository:
|
||||
- Check if the repository exists at the specified path.
|
||||
- If the repository exists, proceed to Step 5.
|
||||
### Step 3: Guide user to set up azure-sdk-for-python repository (if not found)
|
||||
- If the user does not have the repository or the path is invalid:
|
||||
- Go to parent directory of current repo root path.
|
||||
- Provide instructions to fork https://github.com/Azure/azure-sdk-for-python repository to the user's GitHub account.
|
||||
- Provide instructions to clone the forked repository to the local machine:
|
||||
```bash
|
||||
git clone https://github.com/<github-username>/azure-sdk-for-python.git
|
||||
```
|
||||
### Step 4: Set repository path
|
||||
- Consider the cloned path as the path to the azure-sdk-for-python repository.
|
||||
### Step 5: Open azure-sdk-for-python repository in VSCode
|
||||
- Do not ask the user to run tsp compile.
|
||||
- Prompt user to open the azure-sdk-for-python repository in VSCode.
|
||||
### Step 6: Provide SDK generation instructions
|
||||
- Inform user to use the following prompt to start SDK generation using GitHub Copilot agent:
|
||||
```
|
||||
"Help me generate SDK for Python from TypeSpec API specification for project <path to TypeSpec project root>."
|
||||
```
|
||||
### Step 7: Inform user about SDK generation
|
||||
- Inform user to provide link to SDK pull request if they generate SDK locally and created a pull request for it. SDK generation
|
||||
step below will skip it for the language and reuse the pull request link provided by the user.
|
||||
- In some cases, user will come back and make more changes to TypeSpec so start the process from step 1 again.
|
||||
- If user provides a link to SDK pull request then link SDK pull request to release plan if a release plan already exists and skip SDK generation for that language.
|
||||
- If a release plan does not exits then link the SDK pull request when release plan is created.
|
||||
@ -0,0 +1,119 @@
|
||||
---
|
||||
description: "Guide the user to generate and build SDKs locally for a TypeSpec based API spec"
|
||||
---
|
||||
|
||||
# Goal
|
||||
|
||||
Help the user generate and build SDKs locally from TypeSpec API specifications using the `azure-sdk-mcp` tools.
|
||||
|
||||
---
|
||||
|
||||
## Part A: Generate SDK Locally
|
||||
|
||||
### Step 1: Outline workflow
|
||||
|
||||
**Goal**: Ensure the user understands the overall SDK generation and build process before starting.
|
||||
**Actions**:
|
||||
|
||||
- Present the high-level steps involved in generating and building SDK locally:
|
||||
1. Select target language
|
||||
2. Verify SDK repository
|
||||
3. Validate repository path
|
||||
4. Identify path to configuration file
|
||||
5. Generate SDK using `azsdk_package_generate_code` MCP tool
|
||||
6. Identify SDK project path
|
||||
7. Build/Compile SDK using `azsdk_package_build_code` MCP tool
|
||||
- Ask the user to confirm readiness to proceed.
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Select language
|
||||
|
||||
**Goal**: Confirm the target language for SDK generation.
|
||||
**Actions**:
|
||||
|
||||
- Prompt user to choose one of the supported languages:
|
||||
- .NET
|
||||
- Java
|
||||
- JavaScript
|
||||
- Python
|
||||
- Go
|
||||
- Validate input against the allowed list.
|
||||
|
||||
---
|
||||
|
||||
### Step 3: Verify SDK repository
|
||||
|
||||
**Goal**: Ensure the correct Azure SDK language repository is available locally.
|
||||
**Actions**:
|
||||
|
||||
- Prompt user to provide the path to their **locally cloned repository** for the selected language.
|
||||
- Note: The **local folder name can be arbitrary**, but the repository must have originated from one of the official Azure SDK repositories:
|
||||
- `azure-sdk-for-net` (.NET)
|
||||
- `azure-sdk-for-java` (Java)
|
||||
- `azure-sdk-for-js` (JavaScript)
|
||||
- `azure-sdk-for-python` (Python)
|
||||
- `azure-sdk-for-go` (Go)
|
||||
- If the repository is not cloned → instruct user to clone the appropriate remote repository from GitHub.
|
||||
- MCP tool will automatically validate the remote origin and repository structure.
|
||||
|
||||
---
|
||||
|
||||
### Step 4: Validate repository path
|
||||
|
||||
**Actions**:
|
||||
|
||||
- Check if the provided repository path exists and matches the selected SDK language repository.
|
||||
- If invalid → prompt user to re-enter a valid path.
|
||||
|
||||
---
|
||||
|
||||
### Step 5: Identify path to configuration file
|
||||
|
||||
**Goal**: Determine the correct path to the TypeSpec configuration file based on the working context.
|
||||
**Actions**:
|
||||
|
||||
- **Scenario A: Working in a repository cloned from `azure-rest-api-specs`**
|
||||
- Identify the path to `tspconfig.yaml` (local path or HTTPS URL).
|
||||
- The local folder name can be arbitrary; the MCP tool will validate that the remote origin URL points to the official `azure-rest-api-specs` repository.
|
||||
- Example paths (pointing directly to tspconfig.yaml):
|
||||
- `/home/usr/azure-rest-api-specs/specification/contosowidgetmanager/Contoso.Management/tspconfig.yaml`
|
||||
- `https://github.com/Azure/azure-rest-api-specs/blob/4af373fc5826cf5a2365a20dde01c4b2efde48f0/specification/contosowidgetmanager/Contoso.Management/tspconfig.yaml`
|
||||
|
||||
- **Scenario B: Working in one of the official Azure SDK language repositories**
|
||||
(i.e., originally cloned from `azure-sdk-for-net`, `azure-sdk-for-java`, `azure-sdk-for-js`, `azure-sdk-for-python`, `azure-sdk-for-go`)
|
||||
- Identify the path to `tsp-location.yaml`.
|
||||
- The local folder name can be arbitrary; MCP tool will validate the remote origin URL.
|
||||
- Example path:
|
||||
`/home/usr/azure-sdk-for-net/sdk/contoso/Azure.ResourceManager.Contoso/tsp-location.yaml`
|
||||
|
||||
---
|
||||
|
||||
### Step 6: Generate SDK
|
||||
|
||||
**Actions**:
|
||||
|
||||
- Run `azsdk_package_generate_code` MCP tool to generate the SDK locally.
|
||||
|
||||
---
|
||||
|
||||
## Part B: Build / Compile SDK Locally
|
||||
|
||||
### Step 1: Identify SDK project path
|
||||
|
||||
**Goal**: Locate the generated SDK project directory for building/compiling.
|
||||
**Actions**:
|
||||
|
||||
- Find the project directory inside the selected Azure SDK language repository.
|
||||
- Typical structure:
|
||||
`sdk/{service-name}/{package-name}/`
|
||||
- Example:
|
||||
`/path/to/azure-sdk-for-net/contoso/Azure.ResourceManager.Contoso/`
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Build/Compile the SDK
|
||||
|
||||
**Actions**:
|
||||
|
||||
- Run `azsdk_package_build_code` MCP tool to compile the SDK in the identified project directory.
|
||||
@ -57,10 +57,12 @@ Wait for the user to respond with a confirmation before proceeding to Step 1. Us
|
||||
**Goal**: Determine how to generate SDKs
|
||||
**Actions**:
|
||||
1. Present options: "How would you like to generate SDKs?"
|
||||
- Option A: "Generate SDK locally". This is currently supported only for Python. Do not recommend this for other languages.
|
||||
- Option A: "Generate SDK locally".
|
||||
- Option B: "Use SDK generation pipeline"
|
||||
2. Based on selection:
|
||||
- If Option A: Refer to #file:create-sdk-locally.instructions.md and then proceed to Step 6
|
||||
- If Option A:
|
||||
- Follow #file:./local-sdk-workflow.instructions.md to generate and compile the SDK.
|
||||
- After SDK has been generated, to continue the SDK release, users can create the SDK pull request manually then proceed to Step 9.
|
||||
- If Option B: Continue to Step 6
|
||||
**Success Criteria**: SDK generation method selected
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user