|  | <html><body> | 
|  | <style> | 
|  |  | 
|  | body, h1, h2, h3, div, span, p, pre, a { | 
|  | margin: 0; | 
|  | padding: 0; | 
|  | border: 0; | 
|  | font-weight: inherit; | 
|  | font-style: inherit; | 
|  | font-size: 100%; | 
|  | font-family: inherit; | 
|  | vertical-align: baseline; | 
|  | } | 
|  |  | 
|  | body { | 
|  | font-size: 13px; | 
|  | padding: 1em; | 
|  | } | 
|  |  | 
|  | h1 { | 
|  | font-size: 26px; | 
|  | margin-bottom: 1em; | 
|  | } | 
|  |  | 
|  | h2 { | 
|  | font-size: 24px; | 
|  | margin-bottom: 1em; | 
|  | } | 
|  |  | 
|  | h3 { | 
|  | font-size: 20px; | 
|  | margin-bottom: 1em; | 
|  | margin-top: 1em; | 
|  | } | 
|  |  | 
|  | pre, code { | 
|  | line-height: 1.5; | 
|  | font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace; | 
|  | } | 
|  |  | 
|  | pre { | 
|  | margin-top: 0.5em; | 
|  | } | 
|  |  | 
|  | h1, h2, h3, p { | 
|  | font-family: Arial, sans serif; | 
|  | } | 
|  |  | 
|  | h1, h2, h3 { | 
|  | border-bottom: solid #CCC 1px; | 
|  | } | 
|  |  | 
|  | .toc_element { | 
|  | margin-top: 0.5em; | 
|  | } | 
|  |  | 
|  | .firstline { | 
|  | margin-left: 2 em; | 
|  | } | 
|  |  | 
|  | .method  { | 
|  | margin-top: 1em; | 
|  | border: solid 1px #CCC; | 
|  | padding: 1em; | 
|  | background: #EEE; | 
|  | } | 
|  |  | 
|  | .details { | 
|  | font-weight: bold; | 
|  | font-size: 14px; | 
|  | } | 
|  |  | 
|  | </style> | 
|  |  | 
|  | <h1><a href="firebaserules_v1.html">Firebase Rules API</a> . <a href="firebaserules_v1.projects.html">projects</a> . <a href="firebaserules_v1.projects.releases.html">releases</a></h1> | 
|  | <h2>Instance Methods</h2> | 
|  | <p class="toc_element"> | 
|  | <code><a href="#create">create(name, body, x__xgafv=None)</a></code></p> | 
|  | <p class="firstline">Create a `Release`.</p> | 
|  | <p class="toc_element"> | 
|  | <code><a href="#delete">delete(name, x__xgafv=None)</a></code></p> | 
|  | <p class="firstline">Delete a `Release` by resource name.</p> | 
|  | <p class="toc_element"> | 
|  | <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="#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="#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> | 
|  | <pre>Create a `Release`. | 
|  |  | 
|  | Release names should reflect the developer's deployment practices. For | 
|  | example, the release name may include the environment name, application | 
|  | name, application version, or any other name meaningful to the developer. | 
|  | Once a `Release` refers to a `Ruleset`, the rules can be enforced by | 
|  | Firebase Rules-enabled services. | 
|  |  | 
|  | More than one `Release` may be 'live' concurrently. Consider the following | 
|  | three `Release` names for `projects/foo` and the `Ruleset` to which they | 
|  | refer. | 
|  |  | 
|  | Release Name                    | Ruleset Name | 
|  | --------------------------------|------------- | 
|  | projects/foo/releases/prod      | projects/foo/rulesets/uuid123 | 
|  | projects/foo/releases/prod/beta | projects/foo/rulesets/uuid123 | 
|  | projects/foo/releases/prod/v23  | projects/foo/rulesets/uuid456 | 
|  |  | 
|  | The table reflects the `Ruleset` rollout in progress. The `prod` and | 
|  | `prod/beta` releases refer to the same `Ruleset`. However, `prod/v23` | 
|  | refers to a new `Ruleset`. The `Ruleset` reference for a `Release` may be | 
|  | updated using the UpdateRelease method. | 
|  |  | 
|  | Args: | 
|  | name: string, Resource name for the project which owns this `Release`. | 
|  |  | 
|  | 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. | 
|  | "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 | 
|  | 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> | 
|  |  | 
|  | <div class="method"> | 
|  | <code class="details" id="delete">delete(name, x__xgafv=None)</code> | 
|  | <pre>Delete a `Release` by resource name. | 
|  |  | 
|  | Args: | 
|  | name: string, Resource name for the `Release` to delete. | 
|  |  | 
|  | Format: `projects/{project_id}/releases/{release_id}` (required) | 
|  | x__xgafv: string, V1 error format. | 
|  | Allowed values | 
|  | 1 - v1 error format | 
|  | 2 - v2 error format | 
|  |  | 
|  | Returns: | 
|  | 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> | 
|  | </div> | 
|  |  | 
|  | <div class="method"> | 
|  | <code class="details" id="get">get(name, x__xgafv=None)</code> | 
|  | <pre>Get a `Release` by name. | 
|  |  | 
|  | Args: | 
|  | name: string, Resource name of the `Release`. | 
|  |  | 
|  | Format: `projects/{project_id}/releases/{release_id}` (required) | 
|  | 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> | 
|  |  | 
|  | <div class="method"> | 
|  | <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. | 
|  |  | 
|  | Args: | 
|  | 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 | 
|  | the releases, the caller should iterate until the `page_token` on the | 
|  | response is empty. | 
|  | filter: string, `Release` filter. The list method supports filters with restrictions on the | 
|  | `Release.name`, `Release.ruleset_name`, and `Release.test_suite_name`. | 
|  |  | 
|  | Example 1: A filter of 'name=prod*' might return `Release`s with names | 
|  | within 'projects/foo' prefixed with 'prod': | 
|  |  | 
|  | Name                          | Ruleset Name | 
|  | ------------------------------|------------- | 
|  | projects/foo/releases/prod    | projects/foo/rulesets/uuid1234 | 
|  | projects/foo/releases/prod/v1 | projects/foo/rulesets/uuid1234 | 
|  | projects/foo/releases/prod/v2 | projects/foo/rulesets/uuid8888 | 
|  |  | 
|  | Example 2: A filter of `name=prod* ruleset_name=uuid1234` would return only | 
|  | `Release` instances for 'projects/foo' with names prefixed with 'prod' | 
|  | referring to the same `Ruleset` name of 'uuid1234': | 
|  |  | 
|  | Name                          | Ruleset Name | 
|  | ------------------------------|------------- | 
|  | projects/foo/releases/prod    | projects/foo/rulesets/1234 | 
|  | projects/foo/releases/prod/v1 | projects/foo/rulesets/1234 | 
|  |  | 
|  | 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` | 
|  |  | 
|  | Returns: | 
|  | An object of the form: | 
|  |  | 
|  | { # The response for FirebaseRulesService.ListReleases. | 
|  | "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`. | 
|  | "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_next">list_next(previous_request, previous_response)</code> | 
|  | <pre>Retrieves the next page of results. | 
|  |  | 
|  | Args: | 
|  | previous_request: The request for the previous page. (required) | 
|  | previous_response: The response from the request for the previous page. (required) | 
|  |  | 
|  | Returns: | 
|  | A request object that you can call 'execute()' on to request the next | 
|  | page. Returns None if there are no more items in the collection. | 
|  | </pre> | 
|  | </div> | 
|  |  | 
|  | <div class="method"> | 
|  | <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 project which owns this `Release`. | 
|  |  | 
|  | Format: `projects/{project_id}` (required) | 
|  | body: object, The request body. (required) | 
|  | 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 # `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. | 
|  | "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. | 
|  | }, | 
|  | "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> |