feat(servicemanagement): update the API

#### servicemanagement:v1 The following keys were added: - schemas.Documentation.properties.additionalIamInfo.description - schemas.Documentation.properties.additionalIamInfo.type - schemas.ExperimentalFeatures.properties.protobufPythonicTypesEnabled.description - schemas.ExperimentalFeatures.properties.protobufPythonicTypesEnabled.type - schemas.GoSettings.properties.renamedServices.additionalProperties.type - schemas.GoSettings.properties.renamedServices.description - schemas.GoSettings.properties.renamedServices.type The following keys were changed: - schemas.QuotaLimit.properties.unit.description
googleapis · Jan 29, 2025 · 3e22be8 · 3e22be8
1 parent 63c47c4
commit 3e22be8
Show file tree

Hide file tree

Showing 2 changed files with 30 additions and 3 deletions.
diff --git a/discovery/servicemanagement-v1.json b/discovery/servicemanagement-v1.json
@@ -830,7 +830,7 @@
       }
     }
   },
-  "revision": "20240927",
+  "revision": "20241202",
   "rootUrl": "https://servicemanagement.googleapis.com/",
   "schemas": {
     "Advice": {
@@ -1568,6 +1568,10 @@
       "description": "`Documentation` provides the information for describing a service. Example: documentation: summary: > The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: > ... - selector: google.calendar.Calendar.Put description: > ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation.",
       "id": "Documentation",
       "properties": {
+        "additionalIamInfo": {
+          "description": "Optional information about the IAM configuration. This is typically used to link to documentation about a product's IAM roles and permissions.",
+          "type": "string"
+        },
         "documentationRootUrl": {
           "description": "The URL to the root of documentation.",
           "type": "string"
@@ -1783,6 +1787,10 @@
       "description": "Experimental features to be included during client library generation. These fields will be deprecated once the feature graduates and is enabled by default.",
       "id": "ExperimentalFeatures",
       "properties": {
+        "protobufPythonicTypesEnabled": {
+          "description": "Enables generation of protobuf code using new types that are more Pythonic which are included in `protobuf>=5.29.x`. This feature will be enabled by default 1 month after launching the feature in preview packages.",
+          "type": "boolean"
+        },
         "restAsyncIoEnabled": {
           "description": "Enables generation of asynchronous REST clients if `rest` transport is enabled. By default, asynchronous REST clients will not be generated. This feature will be enabled by default 1 month after launching the feature in preview packages.",
           "type": "boolean"
@@ -2035,6 +2043,13 @@
         "common": {
           "$ref": "CommonLanguageSettings",
           "description": "Some settings."
+        },
+        "renamedServices": {
+          "additionalProperties": {
+            "type": "string"
+          },
+          "description": "Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin",
+          "type": "object"
         }
       },
       "type": "object"
@@ -3085,7 +3100,7 @@
           "type": "string"
         },
         "unit": {
-          "description": "Specify the unit of the quota limit. It uses the same syntax as Metric.unit. The supported unit kinds are determined by the quota backend system. Here are some examples: * \"1/min/{project}\" for quota per minute per project. Note: the order of unit components is insignificant. The \"1\" at the beginning is required to follow the metric unit syntax.",
+          "description": "Specify the unit of the quota limit. It uses the same syntax as MetricDescriptor.unit. The supported unit kinds are determined by the quota backend system. Here are some examples: * \"1/min/{project}\" for quota per minute per project. Note: the order of unit components is insignificant. The \"1\" at the beginning is required to follow the metric unit syntax.",
           "type": "string"
         },
         "values": {

diff --git a/src/apis/servicemanagement/v1.ts b/src/apis/servicemanagement/v1.ts
@@ -619,6 +619,10 @@ export namespace servicemanagement_v1 {
    * `Documentation` provides the information for describing a service. Example: documentation: summary: \> The Google Calendar API gives access to most calendar features. pages: - name: Overview content: (== include google/foo/overview.md ==) - name: Tutorial content: (== include google/foo/tutorial.md ==) subpages: - name: Java content: (== include google/foo/tutorial_java.md ==) rules: - selector: google.calendar.Calendar.Get description: \> ... - selector: google.calendar.Calendar.Put description: \> ... Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded. Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided. A number of constructs specific to the API platform are supported in documentation text. In order to reference a proto element, the following notation can be used: [fully.qualified.proto.name][] To override the display text used for the link, this can be used: [display text][fully.qualified.proto.name] Text can be excluded from doc using the following notation: (-- internal comment --) A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: (== include path/to/file ==) The `resource_for` directive marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: (== resource_for v1.shelves.books ==) The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation.
    */
   export interface Schema$Documentation {
+    /**
+     * Optional information about the IAM configuration. This is typically used to link to documentation about a product's IAM roles and permissions.
+     */
+    additionalIamInfo?: string | null;
     /**
      * The URL to the root of documentation.
      */
@@ -773,6 +777,10 @@ export namespace servicemanagement_v1 {
    * Experimental features to be included during client library generation. These fields will be deprecated once the feature graduates and is enabled by default.
    */
   export interface Schema$ExperimentalFeatures {
+    /**
+     * Enables generation of protobuf code using new types that are more Pythonic which are included in `protobuf\>=5.29.x`. This feature will be enabled by default 1 month after launching the feature in preview packages.
+     */
+    protobufPythonicTypesEnabled?: boolean | null;
     /**
      * Enables generation of asynchronous REST clients if `rest` transport is enabled. By default, asynchronous REST clients will not be generated. This feature will be enabled by default 1 month after launching the feature in preview packages.
      */
@@ -934,6 +942,10 @@ export namespace servicemanagement_v1 {
      * Some settings.
      */
     common?: Schema$CommonLanguageSettings;
+    /**
+     * Map of service names to renamed services. Keys are the package relative service names and values are the name to be used for the service client and call options. publishing: go_settings: renamed_services: Publisher: TopicAdmin
+     */
+    renamedServices?: {[key: string]: string} | null;
   }
   /**
    * Defines the HTTP configuration for an API service. It contains a list of HttpRule, each specifying the mapping of an RPC method to one or more HTTP REST API methods.
@@ -1644,7 +1656,7 @@ export namespace servicemanagement_v1 {
      */
     name?: string | null;
     /**
-     * Specify the unit of the quota limit. It uses the same syntax as Metric.unit. The supported unit kinds are determined by the quota backend system. Here are some examples: * "1/min/{project\}" for quota per minute per project. Note: the order of unit components is insignificant. The "1" at the beginning is required to follow the metric unit syntax.
+     * Specify the unit of the quota limit. It uses the same syntax as MetricDescriptor.unit. The supported unit kinds are determined by the quota backend system. Here are some examples: * "1/min/{project\}" for quota per minute per project. Note: the order of unit components is insignificant. The "1" at the beginning is required to follow the metric unit syntax.
      */
     unit?: string | null;
     /**