<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=None, 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, filter=None, pageSize=None, pageToken=None, x__xgafv=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=None, 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=None, x__xgafv=None)</code>
  <pre>Create a `Release`.

Release names should reflect the developer&#x27;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 &#x27;live&#x27; 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.
    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`.
  &quot;name&quot;: &quot;A String&quot;, # 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}`
  &quot;rulesetName&quot;: &quot;A String&quot;, # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
      # exist the `Release` to be created.
  &quot;createTime&quot;: &quot;A String&quot;, # Time the release was created.
      # Output only.
  &quot;updateTime&quot;: &quot;A String&quot;, # Time the release was updated.
      # 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`.
    &quot;name&quot;: &quot;A String&quot;, # 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}`
    &quot;rulesetName&quot;: &quot;A String&quot;, # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
        # exist the `Release` to be created.
    &quot;createTime&quot;: &quot;A String&quot;, # Time the release was created.
        # Output only.
    &quot;updateTime&quot;: &quot;A String&quot;, # Time the release was updated.
        # 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`.
    &quot;name&quot;: &quot;A String&quot;, # 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}`
    &quot;rulesetName&quot;: &quot;A String&quot;, # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
        # exist the `Release` to be created.
    &quot;createTime&quot;: &quot;A String&quot;, # Time the release was created.
        # Output only.
    &quot;updateTime&quot;: &quot;A String&quot;, # Time the release was updated.
        # 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
    &quot;executableVersion&quot;: &quot;A String&quot;, # The Rules runtime version of the executable.
    &quot;updateTime&quot;: &quot;A String&quot;, # Timestamp for the most recent `Release.update_time`.
    &quot;executable&quot;: &quot;A String&quot;, # Executable view of the `Ruleset` referenced by the `Release`.
    &quot;rulesetName&quot;: &quot;A String&quot;, # `Ruleset` name associated with the `Release` executable.
    &quot;syncTime&quot;: &quot;A String&quot;, # Optional, indicates the freshness of the result. The response is
        # guaranteed to be the latest within an interval up to the
        # sync_time (inclusive).
    &quot;language&quot;: &quot;A String&quot;, # `Language` used to generate the executable bytes.
  }</pre>
</div>

<div class="method">
    <code class="details" id="list">list(name, filter=None, pageSize=None, pageToken=None, x__xgafv=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)
  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 &#x27;name=prod*&#x27; might return `Release`s with names
within &#x27;projects/foo&#x27; prefixed with &#x27;prod&#x27;:

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 &#x27;projects/foo&#x27; with names prefixed with &#x27;prod&#x27;
referring to the same `Ruleset` name of &#x27;uuid1234&#x27;:

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`
  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.
  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:

    { # The response for FirebaseRulesService.ListReleases.
    &quot;releases&quot;: [ # 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`.
        &quot;name&quot;: &quot;A String&quot;, # 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}`
        &quot;rulesetName&quot;: &quot;A String&quot;, # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
            # exist the `Release` to be created.
        &quot;createTime&quot;: &quot;A String&quot;, # Time the release was created.
            # Output only.
        &quot;updateTime&quot;: &quot;A String&quot;, # Time the release was updated.
            # Output only.
      },
    ],
    &quot;nextPageToken&quot;: &quot;A String&quot;, # The pagination token to retrieve the next page of results. If the value is
        # empty, no further results remain.
  }</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 &#x27;execute()&#x27; 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=None, 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.
    The object takes the form of:

{ # The request for FirebaseRulesService.UpdateReleasePatch.
    &quot;updateMask&quot;: &quot;A String&quot;, # Specifies which fields to update.
    &quot;release&quot;: { # `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`.
      &quot;name&quot;: &quot;A String&quot;, # 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}`
      &quot;rulesetName&quot;: &quot;A String&quot;, # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
          # exist the `Release` to be created.
      &quot;createTime&quot;: &quot;A String&quot;, # Time the release was created.
          # Output only.
      &quot;updateTime&quot;: &quot;A String&quot;, # Time the release was updated.
          # 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`.
    &quot;name&quot;: &quot;A String&quot;, # 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}`
    &quot;rulesetName&quot;: &quot;A String&quot;, # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
        # exist the `Release` to be created.
    &quot;createTime&quot;: &quot;A String&quot;, # Time the release was created.
        # Output only.
    &quot;updateTime&quot;: &quot;A String&quot;, # Time the release was updated.
        # Output only.
  }</pre>
</div>

</body></html>