Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / python / google-api-python-client / 0a471d3d1d3c16eeda1d1a1288f99be9f8027475 / . / docs / dyn / firebaserules_v1.projects.releases.html
blob: 8d9f299b534994b04e8d62223d5f0d6a8970e164 [file] [log] [blame]
Jon Wayne Parrott0a471d32016-05-19 10:54:38 -0700[diff] [blame^]1<html><body>
2<style>
3
4body, h1, h2, h3, div, span, p, pre, a {
5 margin: 0;
6 padding: 0;
7 border: 0;
8 font-weight: inherit;
9 font-style: inherit;
10 font-size: 100%;
11 font-family: inherit;
12 vertical-align: baseline;
13}
14
15body {
16 font-size: 13px;
17 padding: 1em;
18}
19
20h1 {
21 font-size: 26px;
22 margin-bottom: 1em;
23}
24
25h2 {
26 font-size: 24px;
27 margin-bottom: 1em;
28}
29
30h3 {
31 font-size: 20px;
32 margin-bottom: 1em;
33 margin-top: 1em;
34}
35
36pre, code {
37 line-height: 1.5;
38 font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace;
39}
40
41pre {
42 margin-top: 0.5em;
43}
44
45h1, h2, h3, p {
46 font-family: Arial, sans serif;
47}
48
49h1, h2, h3 {
50 border-bottom: solid #CCC 1px;
51}
52
53.toc_element {
54 margin-top: 0.5em;
55}
56
57.firstline {
58 margin-left: 2 em;
59}
60
61.method {
62 margin-top: 1em;
63 border: solid 1px #CCC;
64 padding: 1em;
65 background: #EEE;
66}
67
68.details {
69 font-weight: bold;
70 font-size: 14px;
71}
72
73</style>
74
75<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>
76<h2>Instance Methods</h2>
77<p class="toc_element">
78 <code><a href="#create">create(name=None, body, x__xgafv=None)</a></code></p>
79<p class="firstline">Create a `Release`.</p>
80<p class="toc_element">
81 <code><a href="#delete">delete(name=None, x__xgafv=None)</a></code></p>
82<p class="firstline">Delete a `Release` by resource name.</p>
83<p class="toc_element">
84 <code><a href="#get">get(name=None, x__xgafv=None)</a></code></p>
85<p class="firstline">Get a `Release` by name.</p>
86<p class="toc_element">
87 <code><a href="#list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</a></code></p>
88<p class="firstline">List the `Release` values for a project. This list may optionally be</p>
89<p class="toc_element">
90 <code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p>
91<p class="firstline">Retrieves the next page of results.</p>
92<p class="toc_element">
93 <code><a href="#update">update(name=None, body, x__xgafv=None)</a></code></p>
94<p class="firstline">Update a `Release`.</p>
95<h3>Method Details</h3>
96<div class="method">
97 <code class="details" id="create">create(name=None, body, x__xgafv=None)</code>
98 <pre>Create a `Release`.
99
100Release names should reflect the developer's deployment practices. For
101example, the release name may include the environment name, application
102name, application version, or any other name meaningful to the developer.
103Once a `Release` refers to a `Ruleset`, the rules can be enforced by
104Firebase Rules-enabled services.
105
106More than one `Release` may be 'live' concurrently. Consider the following
107three `Release` names for `projects/foo` and the `Ruleset` to which they
108refer.
109
110Release Name | Ruleset Name
111--------------------------------|-------------
112projects/foo/releases/prod | projects/foo/rulesets/uuid123
113projects/foo/releases/prod/beta | projects/foo/rulesets/uuid123
114projects/foo/releases/prod/v23 | projects/foo/rulesets/uuid456
115
116The table reflects the `Ruleset` rollout in progress. The `prod` and
117`prod/beta` releases refer to the same `Ruleset`. However, `prod/v23`
118refers to a new `Ruleset`. The `Ruleset` reference for a `Release` may be
119updated using the UpdateRelease method, and the custom `Release` name
120may be referenced by specifying the `X-Firebase-Rules-Release-Name` header.
121
122Args:
123 name: string, Resource name for the project which owns this `Release`.
124
125Format: `projects/{project_id}` (required)
126 body: object, The request body. (required)
127 The object takes the form of:
128
129{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
130 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
131 "updateTime": "A String", # Time the release was updated.
132 # @OutputOnly
133 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
134 # exist the `Release` to be created.
135 "createTime": "A String", # Time the release was created.
136 # @OutputOnly
137 "name": "A String", # Resource name for the `Release`.
138 #
139 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
140 # which affords developers a great deal of flexibility in mapping the name
141 # to the style that best fits their existing development practices. For
142 # example, a name could refer to an environment, an app, a version, or some
143 # combination of three.
144 #
145 # In the table below, for the project name `projects/foo`, the following
146 # relative release paths show how flat and structured names might be chosen
147 # to match a desired development / deployment strategy.
148 #
149 # Use Case | Flat Name | Structured Name
150 # -------------|---------------------|----------------
151 # Environments | releases/qa | releases/qa
152 # Apps | releases/app1_qa | releases/app1/qa
153 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
154 #
155 # The delimiter between the release name path elements can be almost anything
156 # and it should work equally well with the release name list filter, but in
157 # many ways the structured paths provide a clearer picture of the
158 # relationship between `Release` instances.
159 #
160 # Format: `projects/{project_id}/releases/{release_id}`
161 }
162
163 x__xgafv: string, V1 error format.
164 Allowed values
165 1 - v1 error format
166 2 - v2 error format
167
168Returns:
169 An object of the form:
170
171 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
172 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
173 "updateTime": "A String", # Time the release was updated.
174 # @OutputOnly
175 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
176 # exist the `Release` to be created.
177 "createTime": "A String", # Time the release was created.
178 # @OutputOnly
179 "name": "A String", # Resource name for the `Release`.
180 #
181 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
182 # which affords developers a great deal of flexibility in mapping the name
183 # to the style that best fits their existing development practices. For
184 # example, a name could refer to an environment, an app, a version, or some
185 # combination of three.
186 #
187 # In the table below, for the project name `projects/foo`, the following
188 # relative release paths show how flat and structured names might be chosen
189 # to match a desired development / deployment strategy.
190 #
191 # Use Case | Flat Name | Structured Name
192 # -------------|---------------------|----------------
193 # Environments | releases/qa | releases/qa
194 # Apps | releases/app1_qa | releases/app1/qa
195 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
196 #
197 # The delimiter between the release name path elements can be almost anything
198 # and it should work equally well with the release name list filter, but in
199 # many ways the structured paths provide a clearer picture of the
200 # relationship between `Release` instances.
201 #
202 # Format: `projects/{project_id}/releases/{release_id}`
203 }</pre>
204</div>
205
206<div class="method">
207 <code class="details" id="delete">delete(name=None, x__xgafv=None)</code>
208 <pre>Delete a `Release` by resource name.
209
210Args:
211 name: string, Resource name for the `Release` to delete.
212
213Format: `projects/{project_id}/releases/{release_id}` (required)
214 x__xgafv: string, V1 error format.
215 Allowed values
216 1 - v1 error format
217 2 - v2 error format
218
219Returns:
220 An object of the form:
221
222 { # A generic empty message that you can re-use to avoid defining duplicated
223 # empty messages in your APIs. A typical example is to use it as the request
224 # or the response type of an API method. For instance:
225 #
226 # service Foo {
227 # rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty);
228 # }
229 #
230 # The JSON representation for `Empty` is empty JSON object `{}`.
231 }</pre>
232</div>
233
234<div class="method">
235 <code class="details" id="get">get(name=None, x__xgafv=None)</code>
236 <pre>Get a `Release` by name.
237
238
239Args:
240 name: string, Resource name of the `Release`.
241
242
243Format: `projects/{project_id}/releases/{release_id}` (required)
244 x__xgafv: string, V1 error format.
245 Allowed values
246 1 - v1 error format
247 2 - v2 error format
248
249Returns:
250 An object of the form:
251
252 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
253 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
254 "updateTime": "A String", # Time the release was updated.
255 # @OutputOnly
256 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
257 # exist the `Release` to be created.
258 "createTime": "A String", # Time the release was created.
259 # @OutputOnly
260 "name": "A String", # Resource name for the `Release`.
261 #
262 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
263 # which affords developers a great deal of flexibility in mapping the name
264 # to the style that best fits their existing development practices. For
265 # example, a name could refer to an environment, an app, a version, or some
266 # combination of three.
267 #
268 # In the table below, for the project name `projects/foo`, the following
269 # relative release paths show how flat and structured names might be chosen
270 # to match a desired development / deployment strategy.
271 #
272 # Use Case | Flat Name | Structured Name
273 # -------------|---------------------|----------------
274 # Environments | releases/qa | releases/qa
275 # Apps | releases/app1_qa | releases/app1/qa
276 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
277 #
278 # The delimiter between the release name path elements can be almost anything
279 # and it should work equally well with the release name list filter, but in
280 # many ways the structured paths provide a clearer picture of the
281 # relationship between `Release` instances.
282 #
283 # Format: `projects/{project_id}/releases/{release_id}`
284 }</pre>
285</div>
286
287<div class="method">
288 <code class="details" id="list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</code>
289 <pre>List the `Release` values for a project. This list may optionally be
290filtered by `Release` name or `Ruleset` id or both.
291
292Args:
293 name: string, Resource name for the project.
294
295Format: `projects/{project_id}` (required)
296 pageSize: integer, Page size to load. Maximum of 100. Defaults to 10.
297Note: `page_size` is just a hint and the service may choose to load less
298than `page_size` due to the size of the output. To traverse all of the
299releases, caller should iterate until the `page_token` is empty.
300 filter: string, `Release` filter. The list method supports filters with restrictions on the
301`Release` `name` and also on the `Ruleset` `ruleset_name`.
302
303Example 1) A filter of 'name=prod*' might return `Release`s with names
304within 'projects/foo' prefixed with 'prod':
305
306Name | Ruleset Name
307------------------------------|-------------
308projects/foo/releases/prod | projects/foo/rulesets/uuid1234
309projects/foo/releases/prod/v1 | projects/foo/rulesets/uuid1234
310projects/foo/releases/prod/v2 | projects/foo/rulesets/uuid8888
311
312Example 2) A filter of `name=prod* ruleset_name=uuid1234` would return only
313`Release` instances for 'projects/foo' with names prefixed with 'prod'
314referring to the same `Ruleset` name of 'uuid1234':
315
316Name | Ruleset Name
317------------------------------|-------------
318projects/foo/releases/prod | projects/foo/rulesets/1234
319projects/foo/releases/prod/v1 | projects/foo/rulesets/1234
320
321In the examples, the filter parameters refer to the search filters for
322release and ruleset names are relative to the project releases and rulesets
323collections. Fully qualified prefixed may also be used. e.g.
324`name=projects/foo/releases/prod* ruleset_name=projects/foo/rulesets/uuid1`
325 pageToken: string, Next page token for the next batch of `Release` instances.
326 x__xgafv: string, V1 error format.
327 Allowed values
328 1 - v1 error format
329 2 - v2 error format
330
331Returns:
332 An object of the form:
333
334 { # The response for FirebaseRulesService.ListReleases.
335 "nextPageToken": "A String", # The pagination token to retrieve the next page of results. If the value is
336 # empty, no further results remain.
337 "releases": [ # List of `Release` instances.
338 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
339 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
340 "updateTime": "A String", # Time the release was updated.
341 # @OutputOnly
342 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
343 # exist the `Release` to be created.
344 "createTime": "A String", # Time the release was created.
345 # @OutputOnly
346 "name": "A String", # Resource name for the `Release`.
347 #
348 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
349 # which affords developers a great deal of flexibility in mapping the name
350 # to the style that best fits their existing development practices. For
351 # example, a name could refer to an environment, an app, a version, or some
352 # combination of three.
353 #
354 # In the table below, for the project name `projects/foo`, the following
355 # relative release paths show how flat and structured names might be chosen
356 # to match a desired development / deployment strategy.
357 #
358 # Use Case | Flat Name | Structured Name
359 # -------------|---------------------|----------------
360 # Environments | releases/qa | releases/qa
361 # Apps | releases/app1_qa | releases/app1/qa
362 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
363 #
364 # The delimiter between the release name path elements can be almost anything
365 # and it should work equally well with the release name list filter, but in
366 # many ways the structured paths provide a clearer picture of the
367 # relationship between `Release` instances.
368 #
369 # Format: `projects/{project_id}/releases/{release_id}`
370 },
371 ],
372 }</pre>
373</div>
374
375<div class="method">
376 <code class="details" id="list_next">list_next(previous_request, previous_response)</code>
377 <pre>Retrieves the next page of results.
378
379Args:
380 previous_request: The request for the previous page. (required)
381 previous_response: The response from the request for the previous page. (required)
382
383Returns:
384 A request object that you can call 'execute()' on to request the next
385 page. Returns None if there are no more items in the collection.
386 </pre>
387</div>
388
389<div class="method">
390 <code class="details" id="update">update(name=None, body, x__xgafv=None)</code>
391 <pre>Update a `Release`.
392
393Only updates to the `ruleset_name` field will be honored. `Release` rename
394is not supported. To create a `Release` use the CreateRelease method
395instead.
396
397Args:
398 name: string, Resource name for the `Release`.
399
400`Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
401which affords developers a great deal of flexibility in mapping the name
402to the style that best fits their existing development practices. For
403example, a name could refer to an environment, an app, a version, or some
404combination of three.
405
406In the table below, for the project name `projects/foo`, the following
407relative release paths show how flat and structured names might be chosen
408to match a desired development / deployment strategy.
409
410Use Case | Flat Name | Structured Name
411-------------|---------------------|----------------
412Environments | releases/qa | releases/qa
413Apps | releases/app1_qa | releases/app1/qa
414Versions | releases/app1_v2_qa | releases/app1/v2/qa
415
416The delimiter between the release name path elements can be almost anything
417and it should work equally well with the release name list filter, but in
418many ways the structured paths provide a clearer picture of the
419relationship between `Release` instances.
420
421Format: `projects/{project_id}/releases/{release_id}`
422 (required)
423 body: object, The request body. (required)
424 The object takes the form of:
425
426{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
427 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
428 "updateTime": "A String", # Time the release was updated.
429 # @OutputOnly
430 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
431 # exist the `Release` to be created.
432 "createTime": "A String", # Time the release was created.
433 # @OutputOnly
434 "name": "A String", # Resource name for the `Release`.
435 #
436 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
437 # which affords developers a great deal of flexibility in mapping the name
438 # to the style that best fits their existing development practices. For
439 # example, a name could refer to an environment, an app, a version, or some
440 # combination of three.
441 #
442 # In the table below, for the project name `projects/foo`, the following
443 # relative release paths show how flat and structured names might be chosen
444 # to match a desired development / deployment strategy.
445 #
446 # Use Case | Flat Name | Structured Name
447 # -------------|---------------------|----------------
448 # Environments | releases/qa | releases/qa
449 # Apps | releases/app1_qa | releases/app1/qa
450 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
451 #
452 # The delimiter between the release name path elements can be almost anything
453 # and it should work equally well with the release name list filter, but in
454 # many ways the structured paths provide a clearer picture of the
455 # relationship between `Release` instances.
456 #
457 # Format: `projects/{project_id}/releases/{release_id}`
458 }
459
460 x__xgafv: string, V1 error format.
461 Allowed values
462 1 - v1 error format
463 2 - v2 error format
464
465Returns:
466 An object of the form:
467
468 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
469 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
470 "updateTime": "A String", # Time the release was updated.
471 # @OutputOnly
472 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
473 # exist the `Release` to be created.
474 "createTime": "A String", # Time the release was created.
475 # @OutputOnly
476 "name": "A String", # Resource name for the `Release`.
477 #
478 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
479 # which affords developers a great deal of flexibility in mapping the name
480 # to the style that best fits their existing development practices. For
481 # example, a name could refer to an environment, an app, a version, or some
482 # combination of three.
483 #
484 # In the table below, for the project name `projects/foo`, the following
485 # relative release paths show how flat and structured names might be chosen
486 # to match a desired development / deployment strategy.
487 #
488 # Use Case | Flat Name | Structured Name
489 # -------------|---------------------|----------------
490 # Environments | releases/qa | releases/qa
491 # Apps | releases/app1_qa | releases/app1/qa
492 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
493 #
494 # The delimiter between the release name path elements can be almost anything
495 # and it should work equally well with the release name list filter, but in
496 # many ways the structured paths provide a clearer picture of the
497 # relationship between `Release` instances.
498 #
499 # Format: `projects/{project_id}/releases/{release_id}`
500 }</pre>
501</div>
502
503</body></html>