Skip to content

Commit e97ab25

Browse files
feat(ondemandscanning): update the api
#### ondemandscanning:v1 The following keys were added: - schemas.PackageData.properties.licenses (Total Keys: 2) - schemas.PackageVersion.properties.licenses (Total Keys: 2) #### ondemandscanning:v1beta1 The following keys were added: - schemas.PackageData.properties.licenses (Total Keys: 2) - schemas.PackageVersion.properties.licenses (Total Keys: 2)
1 parent f6c9f4c commit e97ab25

File tree

4 files changed

+60
-2
lines changed

4 files changed

+60
-2
lines changed

docs/dyn/ondemandscanning_v1.projects.locations.scans.html

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -103,16 +103,25 @@ <h3>Method Details</h3>
103103
&quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
104104
{
105105
&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.
106+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
107+
&quot;A String&quot;,
108+
],
106109
&quot;name&quot;: &quot;A String&quot;,
107110
&quot;version&quot;: &quot;A String&quot;,
108111
},
109112
&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.
113+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
114+
&quot;A String&quot;,
115+
],
110116
&quot;name&quot;: &quot;A String&quot;,
111117
&quot;version&quot;: &quot;A String&quot;,
112118
},
113119
},
114120
],
115121
&quot;binaryVersion&quot;: { # DEPRECATED
122+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
123+
&quot;A String&quot;,
124+
],
116125
&quot;name&quot;: &quot;A String&quot;,
117126
&quot;version&quot;: &quot;A String&quot;,
118127
},
@@ -129,6 +138,9 @@ <h3>Method Details</h3>
129138
},
130139
],
131140
&quot;hashDigest&quot;: &quot;A String&quot;, # HashDigest stores the SHA512 hash digest of the jar file if the package is of type Maven. This field will be unset for non Maven packages.
141+
&quot;licenses&quot;: [ # The list of licenses found that are related to a given package. Note that licenses may also be stored on the BinarySourceInfo. If there is no BinarySourceInfo (because there&#x27;s no concept of source vs binary), then it will be stored here, while if there are BinarySourceInfos, it will be stored there, as one source can have multiple binaries with different licenses.
142+
&quot;A String&quot;,
143+
],
132144
&quot;maintainer&quot;: { # The maintainer of the package.
133145
&quot;kind&quot;: &quot;A String&quot;,
134146
&quot;name&quot;: &quot;A String&quot;,
@@ -141,6 +153,9 @@ <h3>Method Details</h3>
141153
&quot;A String&quot;,
142154
],
143155
&quot;sourceVersion&quot;: { # DEPRECATED
156+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
157+
&quot;A String&quot;,
158+
],
144159
&quot;name&quot;: &quot;A String&quot;,
145160
&quot;version&quot;: &quot;A String&quot;,
146161
},

docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -102,16 +102,25 @@ <h3>Method Details</h3>
102102
&quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
103103
{
104104
&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.
105+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
106+
&quot;A String&quot;,
107+
],
105108
&quot;name&quot;: &quot;A String&quot;,
106109
&quot;version&quot;: &quot;A String&quot;,
107110
},
108111
&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.
112+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
113+
&quot;A String&quot;,
114+
],
109115
&quot;name&quot;: &quot;A String&quot;,
110116
&quot;version&quot;: &quot;A String&quot;,
111117
},
112118
},
113119
],
114120
&quot;binaryVersion&quot;: { # DEPRECATED
121+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
122+
&quot;A String&quot;,
123+
],
115124
&quot;name&quot;: &quot;A String&quot;,
116125
&quot;version&quot;: &quot;A String&quot;,
117126
},
@@ -128,6 +137,9 @@ <h3>Method Details</h3>
128137
},
129138
],
130139
&quot;hashDigest&quot;: &quot;A String&quot;, # HashDigest stores the SHA512 hash digest of the jar file if the package is of type Maven. This field will be unset for non Maven packages.
140+
&quot;licenses&quot;: [ # The list of licenses found that are related to a given package. Note that licenses may also be stored on the BinarySourceInfo. If there is no BinarySourceInfo (because there&#x27;s no concept of source vs binary), then it will be stored here, while if there are BinarySourceInfos, it will be stored there, as one source can have multiple binaries with different licenses.
141+
&quot;A String&quot;,
142+
],
131143
&quot;maintainer&quot;: { # The maintainer of the package.
132144
&quot;kind&quot;: &quot;A String&quot;,
133145
&quot;name&quot;: &quot;A String&quot;,
@@ -140,6 +152,9 @@ <h3>Method Details</h3>
140152
&quot;A String&quot;,
141153
],
142154
&quot;sourceVersion&quot;: { # DEPRECATED
155+
&quot;licenses&quot;: [ # The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.
156+
&quot;A String&quot;,
157+
],
143158
&quot;name&quot;: &quot;A String&quot;,
144159
&quot;version&quot;: &quot;A String&quot;,
145160
},

googleapiclient/discovery_cache/documents/ondemandscanning.v1.json

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -339,7 +339,7 @@
339339
}
340340
}
341341
},
342-
"revision": "20231009",
342+
"revision": "20231016",
343343
"rootUrl": "https://ondemandscanning.googleapis.com/",
344344
"schemas": {
345345
"AliasContext": {
@@ -1874,6 +1874,13 @@
18741874
"description": "HashDigest stores the SHA512 hash digest of the jar file if the package is of type Maven. This field will be unset for non Maven packages.",
18751875
"type": "string"
18761876
},
1877+
"licenses": {
1878+
"description": "The list of licenses found that are related to a given package. Note that licenses may also be stored on the BinarySourceInfo. If there is no BinarySourceInfo (because there's no concept of source vs binary), then it will be stored here, while if there are BinarySourceInfos, it will be stored there, as one source can have multiple binaries with different licenses.",
1879+
"items": {
1880+
"type": "string"
1881+
},
1882+
"type": "array"
1883+
},
18771884
"maintainer": {
18781885
"$ref": "Maintainer",
18791886
"description": "The maintainer of the package."
@@ -2056,6 +2063,13 @@
20562063
"PackageVersion": {
20572064
"id": "PackageVersion",
20582065
"properties": {
2066+
"licenses": {
2067+
"description": "The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.",
2068+
"items": {
2069+
"type": "string"
2070+
},
2071+
"type": "array"
2072+
},
20592073
"name": {
20602074
"type": "string"
20612075
},

googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -339,7 +339,7 @@
339339
}
340340
}
341341
},
342-
"revision": "20231009",
342+
"revision": "20231016",
343343
"rootUrl": "https://ondemandscanning.googleapis.com/",
344344
"schemas": {
345345
"AliasContext": {
@@ -1869,6 +1869,13 @@
18691869
"description": "HashDigest stores the SHA512 hash digest of the jar file if the package is of type Maven. This field will be unset for non Maven packages.",
18701870
"type": "string"
18711871
},
1872+
"licenses": {
1873+
"description": "The list of licenses found that are related to a given package. Note that licenses may also be stored on the BinarySourceInfo. If there is no BinarySourceInfo (because there's no concept of source vs binary), then it will be stored here, while if there are BinarySourceInfos, it will be stored there, as one source can have multiple binaries with different licenses.",
1874+
"items": {
1875+
"type": "string"
1876+
},
1877+
"type": "array"
1878+
},
18721879
"maintainer": {
18731880
"$ref": "Maintainer",
18741881
"description": "The maintainer of the package."
@@ -2051,6 +2058,13 @@
20512058
"PackageVersion": {
20522059
"id": "PackageVersion",
20532060
"properties": {
2061+
"licenses": {
2062+
"description": "The licenses associated with this package. Note that this has to go on the PackageVersion level, because we can have cases with images with the same source having different licences. E.g. in Alpine, musl and musl-utils both have the same origin musl, but have different sets of licenses.",
2063+
"items": {
2064+
"type": "string"
2065+
},
2066+
"type": "array"
2067+
},
20542068
"name": {
20552069
"type": "string"
20562070
},

0 commit comments

Comments
 (0)