chore: update docs/dyn (#1162)
This PR was generated using Autosynth. :rainbow:
Synth log will be available here:
https://source.cloud.google.com/results/invocations/b5e48daa-1759-436b-9fe7-ffce1482b520/targets
- [ ] To automatically regenerate this PR, check this box.
diff --git a/docs/dyn/firebaserules_v1.projects.releases.html b/docs/dyn/firebaserules_v1.projects.releases.html
index f08a7ea..66754b2 100644
--- a/docs/dyn/firebaserules_v1.projects.releases.html
+++ b/docs/dyn/firebaserules_v1.projects.releases.html
@@ -114,10 +114,10 @@
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`.
- "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}`
- "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}`
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must exist the `Release` to be created.
+ "updateTime": "A String", # Time the release was updated. Output only.
}
x__xgafv: string, V1 error format.
@@ -129,11 +129,11 @@
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`.
- "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}`
- "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.
- }</pre>
+ "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}`
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must exist the `Release` to be created.
+ "updateTime": "A String", # Time the release was updated. Output only.
+}</pre>
</div>
<div class="method">
@@ -151,7 +151,7 @@
An object of the form:
{ # A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method. For instance: service Foo { rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); } The JSON representation for `Empty` is empty JSON object `{}`.
- }</pre>
+}</pre>
</div>
<div class="method">
@@ -169,11 +169,11 @@
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`.
- "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}`
- "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.
- }</pre>
+ "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}`
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must exist the `Release` to be created.
+ "updateTime": "A String", # Time the release was updated. Output only.
+}</pre>
</div>
<div class="method">
@@ -196,13 +196,13 @@
An object of the form:
{ # The response for FirebaseRulesService.GetReleaseExecutable
- "executable": "A String", # Executable view of the `Ruleset` referenced by the `Release`.
- "executableVersion": "A String", # The Rules runtime version of the executable.
- "rulesetName": "A String", # `Ruleset` name associated with the `Release` executable.
- "language": "A String", # `Language` used to generate the executable bytes.
- "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).
- "updateTime": "A String", # Timestamp for the most recent `Release.update_time`.
- }</pre>
+ "executable": "A String", # Executable view of the `Ruleset` referenced by the `Release`.
+ "executableVersion": "A String", # The Rules runtime version of the executable.
+ "language": "A String", # `Language` used to generate the executable bytes.
+ "rulesetName": "A String", # `Ruleset` name associated with the `Release` executable.
+ "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).
+ "updateTime": "A String", # Timestamp for the most recent `Release.update_time`.
+}</pre>
</div>
<div class="method">
@@ -223,16 +223,16 @@
An object of the form:
{ # The response for FirebaseRulesService.ListReleases.
- "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`.
- "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}`
- "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.
- },
- ],
- "nextPageToken": "A String", # The pagination token to retrieve the next page of results. If the value is empty, no further results remain.
- }</pre>
+ "nextPageToken": "A String", # The pagination token to retrieve the next page of results. If the value is 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`.
+ "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}`
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must exist the `Release` to be created.
+ "updateTime": "A String", # Time the release was updated. Output only.
+ },
+ ],
+}</pre>
</div>
<div class="method">
@@ -259,14 +259,14 @@
The object takes the form of:
{ # The request for FirebaseRulesService.UpdateReleasePatch.
- "release": { # `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`. # `Release` to update.
- "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}`
- "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.
- },
- "updateMask": "A String", # Specifies which fields to update.
- }
+ "release": { # `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`. # `Release` to update.
+ "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}`
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must exist the `Release` to be created.
+ "updateTime": "A String", # Time the release was updated. Output only.
+ },
+ "updateMask": "A String", # Specifies which fields to update.
+}
x__xgafv: string, V1 error format.
Allowed values
@@ -277,11 +277,11 @@
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`.
- "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}`
- "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.
- }</pre>
+ "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}`
+ "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must exist the `Release` to be created.
+ "updateTime": "A String", # Time the release was updated. Output only.
+}</pre>
</div>
</body></html>
\ No newline at end of file