You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
515 lines
21 KiB
515 lines
21 KiB
<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> |