Regen all docs. (#700)
* Stop recursing if discovery == {}
* Generate docs with 'make docs'.
diff --git a/docs/dyn/firebaserules_v1.projects.releases.html b/docs/dyn/firebaserules_v1.projects.releases.html
index f4cf4a5..837d63b 100644
--- a/docs/dyn/firebaserules_v1.projects.releases.html
+++ b/docs/dyn/firebaserules_v1.projects.releases.html
@@ -84,14 +84,17 @@
<code><a href="#get">get(name, x__xgafv=None)</a></code></p>
<p class="firstline">Get a `Release` by name.</p>
<p class="toc_element">
- <code><a href="#list">list(name, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</a></code></p>
+ <code><a href="#getExecutable">getExecutable(name, executableVersion=None, x__xgafv=None)</a></code></p>
+<p class="firstline">Get the `Release` executable to use when enforcing rules.</p>
+<p class="toc_element">
+ <code><a href="#list">list(name, pageToken=None, x__xgafv=None, pageSize=None, filter=None)</a></code></p>
<p class="firstline">List the `Release` values for a project. This list may optionally be</p>
<p class="toc_element">
<code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p>
<p class="firstline">Retrieves the next page of results.</p>
<p class="toc_element">
- <code><a href="#update">update(name, body, x__xgafv=None)</a></code></p>
-<p class="firstline">Update a `Release`.</p>
+ <code><a href="#patch">patch(name, body, x__xgafv=None)</a></code></p>
+<p class="firstline">Update a `Release` via PATCH.</p>
<h3>Method Details</h3>
<div class="method">
<code class="details" id="create">create(name, body, x__xgafv=None)</code>
@@ -126,38 +129,38 @@
The object takes the form of:
{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
- # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
- "updateTime": "A String", # Time the release was updated.
- # Output only.
- "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
- # exist the `Release` to be created.
- "createTime": "A String", # Time the release was created.
- # Output only.
- "name": "A String", # Resource name for the `Release`.
- #
- # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
- # which affords developers a great deal of flexibility in mapping the name
- # to the style that best fits their existing development practices. For
- # example, a name could refer to an environment, an app, a version, or some
- # combination of three.
- #
- # In the table below, for the project name `projects/foo`, the following
- # relative release paths show how flat and structured names might be chosen
- # to match a desired development / deployment strategy.
- #
- # Use Case | Flat Name | Structured Name
- # -------------|---------------------|----------------
- # Environments | releases/qa | releases/qa
- # Apps | releases/app1_qa | releases/app1/qa
- # Versions | releases/app1_v2_qa | releases/app1/v2/qa
- #
- # The delimiter between the release name path elements can be almost anything
- # and it should work equally well with the release name list filter, but in
- # many ways the structured paths provide a clearer picture of the
- # relationship between `Release` instances.
- #
- # Format: `projects/{project_id}/releases/{release_id}`
- }
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # Output only.
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ "createTime": "A String", # Time the release was created.
+ # Output only.
+}
x__xgafv: string, V1 error format.
Allowed values
@@ -168,38 +171,38 @@
An object of the form:
{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
- # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
- "updateTime": "A String", # Time the release was updated.
- # Output only.
- "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
- # exist the `Release` to be created.
- "createTime": "A String", # Time the release was created.
- # Output only.
- "name": "A String", # Resource name for the `Release`.
- #
- # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
- # which affords developers a great deal of flexibility in mapping the name
- # to the style that best fits their existing development practices. For
- # example, a name could refer to an environment, an app, a version, or some
- # combination of three.
- #
- # In the table below, for the project name `projects/foo`, the following
- # relative release paths show how flat and structured names might be chosen
- # to match a desired development / deployment strategy.
- #
- # Use Case | Flat Name | Structured Name
- # -------------|---------------------|----------------
- # Environments | releases/qa | releases/qa
- # Apps | releases/app1_qa | releases/app1/qa
- # Versions | releases/app1_v2_qa | releases/app1/v2/qa
- #
- # The delimiter between the release name path elements can be almost anything
- # and it should work equally well with the release name list filter, but in
- # many ways the structured paths provide a clearer picture of the
- # relationship between `Release` instances.
- #
- # Format: `projects/{project_id}/releases/{release_id}`
- }</pre>
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # Output only.
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ "createTime": "A String", # Time the release was created.
+ # Output only.
+ }</pre>
</div>
<div class="method">
@@ -247,42 +250,72 @@
An object of the form:
{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
- # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
- "updateTime": "A String", # Time the release was updated.
- # Output only.
- "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
- # exist the `Release` to be created.
- "createTime": "A String", # Time the release was created.
- # Output only.
- "name": "A String", # Resource name for the `Release`.
- #
- # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
- # which affords developers a great deal of flexibility in mapping the name
- # to the style that best fits their existing development practices. For
- # example, a name could refer to an environment, an app, a version, or some
- # combination of three.
- #
- # In the table below, for the project name `projects/foo`, the following
- # relative release paths show how flat and structured names might be chosen
- # to match a desired development / deployment strategy.
- #
- # Use Case | Flat Name | Structured Name
- # -------------|---------------------|----------------
- # Environments | releases/qa | releases/qa
- # Apps | releases/app1_qa | releases/app1/qa
- # Versions | releases/app1_v2_qa | releases/app1/v2/qa
- #
- # The delimiter between the release name path elements can be almost anything
- # and it should work equally well with the release name list filter, but in
- # many ways the structured paths provide a clearer picture of the
- # relationship between `Release` instances.
- #
- # Format: `projects/{project_id}/releases/{release_id}`
- }</pre>
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # Output only.
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ "createTime": "A String", # Time the release was created.
+ # Output only.
+ }</pre>
</div>
<div class="method">
- <code class="details" id="list">list(name, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</code>
+ <code class="details" id="getExecutable">getExecutable(name, executableVersion=None, x__xgafv=None)</code>
+ <pre>Get the `Release` executable to use when enforcing rules.
+
+Args:
+ name: string, Resource name of the `Release`.
+
+Format: `projects/{project_id}/releases/{release_id}` (required)
+ executableVersion: string, The requested runtime executable version.
+Defaults to FIREBASE_RULES_EXECUTABLE_V1.
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # The response for FirebaseRulesService.GetReleaseExecutable
+ "executable": "A String", # Executable view of the `Ruleset` referenced by the `Release`.
+ "language": "A String", # `Language` used to generate the executable bytes.
+ "rulesetName": "A String", # `Ruleset` name associated with the `Release` executable.
+ "updateTime": "A String", # Timestamp for the most recent `Release.update_time`.
+ "syncTime": "A String", # Optional, indicates the freshness of the result. The response is
+ # guaranteed to be the latest within an interval up to the
+ # sync_time (inclusive).
+ "executableVersion": "A String", # The Rules runtime version of the executable.
+ }</pre>
+</div>
+
+<div class="method">
+ <code class="details" id="list">list(name, pageToken=None, x__xgafv=None, pageSize=None, filter=None)</code>
<pre>List the `Release` values for a project. This list may optionally be
filtered by `Release` name, `Ruleset` name, `TestSuite` name, or any
combination thereof.
@@ -291,6 +324,11 @@
name: string, Resource name for the project.
Format: `projects/{project_id}` (required)
+ pageToken: string, Next page token for the next batch of `Release` instances.
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
pageSize: integer, Page size to load. Maximum of 100. Defaults to 10.
Note: `page_size` is just a hint and the service may choose to load fewer
than `page_size` results due to the size of the output. To traverse all of
@@ -320,11 +358,6 @@
In the examples, the filter parameters refer to the search filters are
relative to the project. Fully qualified prefixed may also be used. e.g.
`test_suite_name=projects/foo/testsuites/uuid1`
- pageToken: string, Next page token for the next batch of `Release` instances.
- x__xgafv: string, V1 error format.
- Allowed values
- 1 - v1 error format
- 2 - v2 error format
Returns:
An object of the form:
@@ -334,38 +367,38 @@
# empty, no further results remain.
"releases": [ # List of `Release` instances.
{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
- # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
- "updateTime": "A String", # Time the release was updated.
- # Output only.
- "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
- # exist the `Release` to be created.
- "createTime": "A String", # Time the release was created.
- # Output only.
- "name": "A String", # Resource name for the `Release`.
- #
- # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
- # which affords developers a great deal of flexibility in mapping the name
- # to the style that best fits their existing development practices. For
- # example, a name could refer to an environment, an app, a version, or some
- # combination of three.
- #
- # In the table below, for the project name `projects/foo`, the following
- # relative release paths show how flat and structured names might be chosen
- # to match a desired development / deployment strategy.
- #
- # Use Case | Flat Name | Structured Name
- # -------------|---------------------|----------------
- # Environments | releases/qa | releases/qa
- # Apps | releases/app1_qa | releases/app1/qa
- # Versions | releases/app1_v2_qa | releases/app1/v2/qa
- #
- # The delimiter between the release name path elements can be almost anything
- # and it should work equally well with the release name list filter, but in
- # many ways the structured paths provide a clearer picture of the
- # relationship between `Release` instances.
- #
- # Format: `projects/{project_id}/releases/{release_id}`
- },
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # Output only.
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ "createTime": "A String", # Time the release was created.
+ # Output only.
+ },
],
}</pre>
</div>
@@ -385,91 +418,27 @@
</div>
<div class="method">
- <code class="details" id="update">update(name, body, x__xgafv=None)</code>
- <pre>Update a `Release`.
+ <code class="details" id="patch">patch(name, body, x__xgafv=None)</code>
+ <pre>Update a `Release` via PATCH.
Only updates to the `ruleset_name` and `test_suite_name` fields will be
honored. `Release` rename is not supported. To create a `Release` use the
CreateRelease method.
Args:
- name: string, Resource name for the `Release`.
+ name: string, Resource name for the project which owns this `Release`.
-`Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
-which affords developers a great deal of flexibility in mapping the name
-to the style that best fits their existing development practices. For
-example, a name could refer to an environment, an app, a version, or some
-combination of three.
-
-In the table below, for the project name `projects/foo`, the following
-relative release paths show how flat and structured names might be chosen
-to match a desired development / deployment strategy.
-
-Use Case | Flat Name | Structured Name
--------------|---------------------|----------------
-Environments | releases/qa | releases/qa
-Apps | releases/app1_qa | releases/app1/qa
-Versions | releases/app1_v2_qa | releases/app1/v2/qa
-
-The delimiter between the release name path elements can be almost anything
-and it should work equally well with the release name list filter, but in
-many ways the structured paths provide a clearer picture of the
-relationship between `Release` instances.
-
-Format: `projects/{project_id}/releases/{release_id}` (required)
+Format: `projects/{project_id}` (required)
body: object, The request body. (required)
The object takes the form of:
-{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
- # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
- "updateTime": "A String", # Time the release was updated.
- # Output only.
- "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
- # exist the `Release` to be created.
- "createTime": "A String", # Time the release was created.
- # Output only.
- "name": "A String", # Resource name for the `Release`.
- #
- # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
- # which affords developers a great deal of flexibility in mapping the name
- # to the style that best fits their existing development practices. For
- # example, a name could refer to an environment, an app, a version, or some
- # combination of three.
- #
- # In the table below, for the project name `projects/foo`, the following
- # relative release paths show how flat and structured names might be chosen
- # to match a desired development / deployment strategy.
- #
- # Use Case | Flat Name | Structured Name
- # -------------|---------------------|----------------
- # Environments | releases/qa | releases/qa
- # Apps | releases/app1_qa | releases/app1/qa
- # Versions | releases/app1_v2_qa | releases/app1/v2/qa
- #
- # The delimiter between the release name path elements can be almost anything
- # and it should work equally well with the release name list filter, but in
- # many ways the structured paths provide a clearer picture of the
- # relationship between `Release` instances.
- #
- # Format: `projects/{project_id}/releases/{release_id}`
- }
-
- x__xgafv: string, V1 error format.
- Allowed values
- 1 - v1 error format
- 2 - v2 error format
-
-Returns:
- An object of the form:
-
- { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+{ # The request for FirebaseRulesService.UpdateReleasePatch.
+ "release": { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a # `Release` to update.
# `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
"updateTime": "A String", # Time the release was updated.
# Output only.
"rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
# exist the `Release` to be created.
- "createTime": "A String", # Time the release was created.
- # Output only.
"name": "A String", # Resource name for the `Release`.
#
# `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
@@ -494,7 +463,53 @@
# relationship between `Release` instances.
#
# Format: `projects/{project_id}/releases/{release_id}`
- }</pre>
+ "createTime": "A String", # Time the release was created.
+ # Output only.
+ },
+ "updateMask": "A String", # Specifies which fields to update.
+ }
+
+ x__xgafv: string, V1 error format.
+ Allowed values
+ 1 - v1 error format
+ 2 - v2 error format
+
+Returns:
+ An object of the form:
+
+ { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
+ # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
+ "updateTime": "A String", # Time the release was updated.
+ # Output only.
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
+ # exist the `Release` to be created.
+ "name": "A String", # Resource name for the `Release`.
+ #
+ # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
+ # which affords developers a great deal of flexibility in mapping the name
+ # to the style that best fits their existing development practices. For
+ # example, a name could refer to an environment, an app, a version, or some
+ # combination of three.
+ #
+ # In the table below, for the project name `projects/foo`, the following
+ # relative release paths show how flat and structured names might be chosen
+ # to match a desired development / deployment strategy.
+ #
+ # Use Case | Flat Name | Structured Name
+ # -------------|---------------------|----------------
+ # Environments | releases/qa | releases/qa
+ # Apps | releases/app1_qa | releases/app1/qa
+ # Versions | releases/app1_v2_qa | releases/app1/v2/qa
+ #
+ # The delimiter between the release name path elements can be almost anything
+ # and it should work equally well with the release name list filter, but in
+ # many ways the structured paths provide a clearer picture of the
+ # relationship between `Release` instances.
+ #
+ # Format: `projects/{project_id}/releases/{release_id}`
+ "createTime": "A String", # Time the release was created.
+ # Output only.
+ }</pre>
</div>
</body></html>
\ No newline at end of file