Merge branch 'main' into go-validation

Author: JiaqiZhang-Dev

.github/CODEOWNERS

@@ -208,10 +208,10 @@
 /specification/scheduler/ @pinwang81
 
 # PRLabel: %Search
-/specification/search/data-plane/ @arv100kri @bleroy @BevLoh @giulianob
+/specification/search/data-plane/ @kuanlu95 @BevLoh @giulianob
 
 # PRLabel: %Search
-/specification/search/resource-manager/ @efrainretana @conor-joplin @BevLoh @xiong-qiao @jonathanserbent @Draconicida @kuanlu95 @admayber
+/specification/search/resource-manager/ @efrainretana @BevLoh @xiong-qiao @jonathanserbent @Draconicida @kuanlu95 @admayber
 
 /specification/serialconsole/ @amitchat @craigw @asinn826
 

.github/copilot-instructions.md

@@ -220,3 +220,16 @@ Do not skip the step that choose SDK generation method to ensure the user select
 
 ## Release readiness of SDK and information about the release pipeline
 Run [check package readiness](..\eng\common\instructions\azsdk-tools\check-package-readiness.instructions.md) to check the release readiness of an SDK package. This prompt will collect the required information from the user, execute the readiness check, and present the results.
+
+## Instructions for GitHub coding agent to generate SDKs using GitHub.com
+Run only SDK generation step and Update SDK details back in issue description and release plan. Do not run TypeSpec validation, or service label check. This is applicable only when GitHub copilot coding agent is used to generate SDK and if a Release Plan is available in the context.
+Coding agent must wait until all SDK generation pipeline are in completed status and then fetch the SDK details from pipeline run. This is applicable only when a GitHub issue is assigned to GitHub coding agent to generate SDK from a TypeSpec project. This is not applicable when running Copilot from Visual Studio and VS Code.
+  
+  steps:
+    - Run SDK generation pipeline for the given TypeSpec path for all languages mentioned in the description.
+    - Keep checking the pipeline status until pipeline is in completed or failed status.
+    - Find SDK pull request links from the pipeline run.
+  constraints:
+    - Do not invoke other steps.
+    - Do not modify main.tsp file or any files in TypeSpec project.
+    - Do not add API version to an existing main.tsp if input API version is not present.

.github/dependabot.yml

@@ -17,9 +17,6 @@ updates:
       - dependency-name: "typescript"
       # Updated manually by the Liftr team
       - dependency-name: "@azure-tools/typespec-liftr-base"
-      - dependency-name: "@types/js-yaml"
-      - dependency-name: "autorest"
-      - dependency-name: "js-yaml"
       # Only allow patch updates for spec-gen-sdk
       - dependency-name: "@azure-tools/spec-gen-sdk"
         update-types: ["version-update:semver-minor", "version-update:semver-major"]
@@ -38,9 +35,6 @@ updates:
       eslint:
         patterns:
           - "*eslint*"
-      openapi-validator:
-        patterns:
-          - "@microsoft.azure/openapi-validator*"
     versioning-strategy: increase-if-necessary
   - package-ecosystem: "npm"
     directories:
@@ -58,8 +52,6 @@ updates:
       - dependency-name: "typescript"
       # Points to "github:actions/github-script" since package isn't published to npmjs
       - dependency-name: "@types/github-script"
-      # Stay on ^7 until ^10 increases in adoption
-      - dependency-name: "cross-env"
     groups:
       eslint:
         patterns:

.github/instructions/openapi-review.instructions.md

@@ -0,0 +1,36 @@
+---
+applyTo: "**/*.json"
+---
+
+# Copilot Review Instructions for reviewing OpenAPI v2
+
+Please review OpenAPI v2 (Swagger) definition files with the following in mind:
+
+## API Guidelines Alignment
+
+- Ensure the API follows https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md.
+- Validate naming conventions for paths, parameters, and schemas.
+- Confirm consistent use of `x-ms-*` extensions where applicable.
+- Check for proper use of `operationId`, `description`, and `summary` fields.
+
+## Versioning
+
+- Ensure the API version is clearly defined and follows the `YYYY-MM-DD` format.
+- Confirm that breaking changes are not introduced in minor version updates.
+
+## Security
+
+- Validate that security definitions (e.g., OAuth2 scopes) are present and correctly applied.
+- Ensure no unsecured endpoints are exposed unless explicitly documented.
+
+## Documentation
+
+- Flag missing or vague descriptions for operations, parameters, and responses.
+- Recommend examples for request/response bodies where missing.
+
+## Style
+
+- Prefer camelCase for property names.
+- Avoid abbreviations unless industry-standard.
+
+Respond in markdown format with clear suggestions and highlight any violations of the guidelines.

.github/package-lock.json

@@ -26,8 +26,6 @@ describe("readme", () => {
     expect(readme.path).toBe(resolve("/specs/foo/readme.md"));
   });
 
-  // TODO: Test that path is resolved against backpointer
-
   it("can be created with string content", async () => {
     const folder = "/fake";
     const readme = new Readme(resolve(folder, "readme.md"), {
@@ -51,6 +49,59 @@ describe("readme", () => {
     expect(swaggerPaths.sort()).toEqual(expectedPaths.sort());
   });
 
+  // If tag names are duplicated (with no disambiguating conditionals), it's almost certainly a bug
+  // in the readme that should be fixed.
+  it("throws if duplicate tags", async () => {
+    let content = `
+\`\`\`yaml $(tag) == 'package-2025-01-01'
+input-file:
+  - foo.json
+\`\`\`
+\`\`\`yaml $(tag) == 'package-2025-01-01'
+input-file:
+  - bar.json
+\`\`\`
+`;
+
+    let readme = new Readme("foo", { ...options, content });
+
+    expect(readme.getTags()).rejects.toThrowError(
+      "Multiple input-file definitions for tag package-2025-01-01",
+    );
+  });
+
+  // A few existing specs use duplicate tags, but with conditionals to disambiguate at runtime.
+  //
+  // While this may work for generating the SDK itself (where you can specify the additional values),
+  // it doesn't work for static analysis tools like LintDiff, since LintDiff wouldn't know what
+  // additional values to pass to autorest.
+  //
+  // It may be possible to support this in spec-model, by allowing duplicate tags with different conditionals.
+  // However, downstream users of the tags for static analysis would still need to throw.  Also, we only
+  // found two specs using this pattern (and only in the private repo).  So I think it's better to continue
+  // disallowing this, and instead rename the conflicting tags in the readme.  Rather than adding
+  // complexity to spec-model for an edge case (with workarounds).
+  //
+  // More details: https://github.com/Azure/azure-rest-api-specs/issues/37003
+  it("throws if duplicate tags with different conditionals", async () => {
+    let content = `
+\`\`\`yaml $(tag) == 'package-2025-01-01'
+input-file:
+  - foo.json
+\`\`\`
+\`\`\`yaml $(tag) == 'package-2025-01-01' && $(test-condition)
+input-file:
+  - bar.json
+\`\`\`
+`;
+
+    let readme = new Readme("foo", { ...options, content });
+
+    expect(readme.getTags()).rejects.toThrowError(
+      "Multiple input-file definitions for tag package-2025-01-01",
+    );
+  });
+
   it("can be created with empty content", async () => {
     const folder = "/fake";
     const readme = new Readme(resolve(folder, "readme.md"), {

.github/shared/package-lock.json

@@ -2,6 +2,13 @@ name: SDK Suppressions
 
 on:
   pull_request:
+    types:
+      # default
+      - opened
+      - synchronize
+      - reopened
+      # re-run if base branch is changed, since previous merge commit may generate incorrect diff
+      - edited
     branches:
       - main
       - RPSaaSMaster

.github/shared/test/readme.test.js

@@ -2,6 +2,13 @@ name: ARM Incremental TypeSpec
 
 on:
   pull_request:
+    types:
+      # default
+      - opened
+      - synchronize
+      - reopened
+      # re-run if base branch is changed, since previous merge commit may generate incorrect diff
+      - edited
     paths:
       # Always trigger on changes to WF itself
       - ".github/**"

.github/workflows/SDK-Suppressions-Label.yaml

@@ -1,6 +1,14 @@
 name: "Swagger Avocado - Analyze Code"
 
-on: pull_request
+on:
+  pull_request:
+    types:
+      # default
+      - opened
+      - synchronize
+      - reopened
+      # re-run if base branch is changed, since previous merge commit may generate incorrect diff
+      - edited
 
 permissions:
   contents: read