feat(ondemandscanning): update the api

yoshi-automation · yoshi-automation · commit e72efccd79dd · 2023-05-30T07:08:04.000Z
#### ondemandscanning:v1

The following keys were added:
- schemas.BinarySourceInfo (Total Keys: 4)
- schemas.PackageData.properties.binarySourceInfo (Total Keys: 2)

#### ondemandscanning:v1beta1

The following keys were added:
- schemas.BinarySourceInfo (Total Keys: 4)
- schemas.PackageData.properties.binarySourceInfo (Total Keys: 2)
diff --git a/docs/dyn/ondemandscanning_v1.projects.locations.scans.html b/docs/dyn/ondemandscanning_v1.projects.locations.scans.html
@@ -100,7 +100,19 @@ <h3>Method Details</h3>
   &quot;packages&quot;: [ # The packages to analyze.
     {
       &quot;architecture&quot;: &quot;A String&quot;, # The architecture of the package.
-      &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+      &quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
+        {
+          &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+          &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+        },
+      ],
+      &quot;binaryVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
@@ -128,7 +140,7 @@ <h3>Method Details</h3>
       &quot;patchedCve&quot;: [ # CVEs that this package is no longer vulnerable to go/drydock-dd-custom-binary-scanning
         &quot;A String&quot;,
       ],
-      &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+      &quot;sourceVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
diff --git a/docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html b/docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html
@@ -99,7 +99,19 @@ <h3>Method Details</h3>
   &quot;packages&quot;: [ # The packages to analyze.
     {
       &quot;architecture&quot;: &quot;A String&quot;, # The architecture of the package.
-      &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+      &quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
+        {
+          &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+          &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+        },
+      ],
+      &quot;binaryVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
@@ -127,7 +139,7 @@ <h3>Method Details</h3>
       &quot;patchedCve&quot;: [ # CVEs that this package is no longer vulnerable to go/drydock-dd-custom-binary-scanning
         &quot;A String&quot;,
       ],
-      &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+      &quot;sourceVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
diff --git a/googleapiclient/discovery_cache/documents/ondemandscanning.v1.json b/googleapiclient/discovery_cache/documents/ondemandscanning.v1.json
@@ -339,7 +339,7 @@
       }
     }
   },
-  "revision": "20230517",
+  "revision": "20230522",
   "rootUrl": "https://ondemandscanning.googleapis.com/",
   "schemas": {
     "AliasContext": {
@@ -506,6 +506,20 @@
       },
       "type": "object"
     },
+    "BinarySourceInfo": {
+      "id": "BinarySourceInfo",
+      "properties": {
+        "binaryVersion": {
+          "$ref": "PackageVersion",
+          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+        },
+        "sourceVersion": {
+          "$ref": "PackageVersion",
+          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+        }
+      },
+      "type": "object"
+    },
     "BuildOccurrence": {
       "description": "Details of a build occurrence.",
       "id": "BuildOccurrence",
@@ -1750,9 +1764,16 @@
           "description": "The architecture of the package.",
           "type": "string"
         },
+        "binarySourceInfo": {
+          "description": "A bundle containing the binary and source information.",
+          "items": {
+            "$ref": "BinarySourceInfo"
+          },
+          "type": "array"
+        },
         "binaryVersion": {
           "$ref": "PackageVersion",
-          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+          "description": "DEPRECATED"
         },
         "cpeUri": {
           "description": "The cpe_uri in [cpe format] (https://cpe.mitre.org/specification/) in which the vulnerability may manifest. Examples include distro or storage location for vulnerable jar.",
@@ -1823,7 +1844,7 @@
         },
         "sourceVersion": {
           "$ref": "PackageVersion",
-          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+          "description": "DEPRECATED"
         },
         "unused": {
           "type": "string"
diff --git a/googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json b/googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json
@@ -339,7 +339,7 @@
       }
     }
   },
-  "revision": "20230517",
+  "revision": "20230522",
   "rootUrl": "https://ondemandscanning.googleapis.com/",
   "schemas": {
     "AliasContext": {
@@ -502,6 +502,20 @@
       },
       "type": "object"
     },
+    "BinarySourceInfo": {
+      "id": "BinarySourceInfo",
+      "properties": {
+        "binaryVersion": {
+          "$ref": "PackageVersion",
+          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+        },
+        "sourceVersion": {
+          "$ref": "PackageVersion",
+          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+        }
+      },
+      "type": "object"
+    },
     "BuildOccurrence": {
       "description": "Details of a build occurrence.",
       "id": "BuildOccurrence",
@@ -1746,9 +1760,16 @@
           "description": "The architecture of the package.",
           "type": "string"
         },
+        "binarySourceInfo": {
+          "description": "A bundle containing the binary and source information.",
+          "items": {
+            "$ref": "BinarySourceInfo"
+          },
+          "type": "array"
+        },
         "binaryVersion": {
           "$ref": "PackageVersion",
-          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+          "description": "DEPRECATED"
         },
         "cpeUri": {
           "description": "The cpe_uri in [cpe format] (https://cpe.mitre.org/specification/) in which the vulnerability may manifest. Examples include distro or storage location for vulnerable jar.",
@@ -1819,7 +1840,7 @@
         },
         "sourceVersion": {
           "$ref": "PackageVersion",
-          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+          "description": "DEPRECATED"
         },
         "unused": {
           "type": "string"
