Merge branch 'main' into google-vertexai-completion-chatcompletion

Author: l-trotta

.github/validate-pr/index.js

@@ -90,7 +90,12 @@ async function run() {
     if (file.startsWith('specification/_spec_utils')) continue
     if (file.startsWith('specification/_doc_ids')) continue
     if (file.startsWith('specification/_json_spec')) continue
-    if (file === 'specification/tsconfig.json') continue
+    if (file.startsWith('specification/node_modules')) continue
+    if (file.endsWith('tsconfig.json')) continue
+    if (file.endsWith('eslint.config.js')) continue
+    if (file.endsWith('package.json')) continue
+    if (file.endsWith('package-lock.json')) continue
+    if (file.endsWith('.md')) continue
     if (getApi(file).endsWith('_types')) {
       const apis = specification.endpoints
         .filter(endpoint => endpoint.name.split('.').filter(s => !privateNames.includes(s))[0] === getApi(file).split('.')[0])

Makefile

@@ -2,6 +2,7 @@ SHELL := /bin/bash
 
 validate: ## Validate a given endpoint request or response
 	@node compiler/run-validations.js --api $(api) --type $(type) --branch $(branch)
+	@npm run lint --prefix specification
 
 validate-no-cache: ## Validate a given endpoint request or response without local cache
 	@node compiler/run-validations.js --api $(api) --type $(type) --branch $(branch) --no-cache
@@ -39,6 +40,8 @@ setup:	## Install dependencies for contrib target
 	@make clean-dep
 	@npm install --prefix compiler
 	@npm install --prefix typescript-generator
+	@npm install --prefix validator
+	@npm install --prefix specification
 	@npm install @redocly/cli
 
 clean-dep:	## Clean npm dependencies

docs/overlays/elasticsearch-openapi-overlays.yaml

@@ -60,4 +60,9 @@ actions:
       security:
         - apiKeyAuth: []
         - basicAuth: []
-        - bearerAuth: []
+        - bearerAuth: []
+# Abbreviate and annotate items that are not shown in Bump.sh due to depth limits
+  - target: "$.components['schemas']['_types.aggregations.RandomSamplerAggregation']"
+    description: Add x-model
+    update:
+      x-model: true

docs/overlays/elasticsearch-shared-overlays.yaml

@@ -915,10 +915,6 @@ actions:
     description: Add x-model
     update:
       x-model: true
-  - target: "$.components['schemas']['_types.aggregations.RandomSamplerAggregation']"
-    description: Add x-model
-    update:
-      x-model: true
   - target: "$.components['schemas']['_types.aggregations.RareTermsAggregation']"
     description: Add x-model
     update:
@@ -1066,6 +1062,16 @@ actions:
       x-model: true
       externalDocs:
         url: https://www.elastic.co/docs/reference/elasticsearch/rest-apis/collapse-search-results
+  - target: "$.components['schemas']['indices._types.IndexSettings']"
+    description: Add x-model and externalDocs for IndexSettings component
+    update:
+      x-model: true
+      externalDocs:
+        description: Index settings
+        url: https://www.elastic.co/docs/reference/elasticsearch/index-settings/
+  - target: "$.components['schemas']['indices._types.IndexSettings'].properties"
+    description: Remove properties IndexSettings object
+    remove: true
   # - target: "$.components['schemas']['_global.msearch.MultisearchBody'].properties"
   #   description: Add x-model
   #   update:

docs/specification-structure.md

@@ -1,7 +1,7 @@
 # Specification structure
 
 The [`/specification`](../specification) folders follows a set of rules to
-keep the defintion easy to access and contribute, while maintaing
+keep the definition easy to access and contribute, while maintaining
 the generated schema consistent and useful for language generators.
 
 ## Rules
@@ -14,7 +14,7 @@ root of the [`/specification`](../specification) folder as well
 as inside the namespaces when necessary.
 
 You should decide if a type should go inside the top-level `_types`
-folder or inside a namespace (eg: `indices/_types`) on a case by case basis.
+folder or inside a namespace (e.g.: `indices/_types`) on a case by case basis.
 A good rule of thumb is that if a type is widely used in the specification,
 it should go in the top level `_types`, while if it's used only within
 a namespace or a few times in other namespaces, it could go inside the
@@ -29,8 +29,8 @@ end with `Request` or `Response`.
 
 ### Request and Response definitions
 
-Request and Reponse definitions should be placed by structly following
-the rest-api-spec structure.
+Request and Response definitions should be placed by strictly following
+the `rest-api-spec` structure.
 For example, the request and response definition for `indices.put_mapping`
 should go in [`/specification/indices/put_mapping`](../specification/indices/put_mapping).
 There are no requirements on the file name, but the type should be
@@ -45,4 +45,4 @@ For example: [`/specification/_global/search`](../specification/_global/search).
 ### Specification helpers
 
 The specification has a set of custom types used to define complex structures
-or behaviors. Those types must be placed in [`/specification/_spec_utils`](../specification/_spec_utils).
+or behaviors. Those types must be placed in [`/specification/_spec_utils`](../specification/_spec_utils).