Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / python / google-api-python-client / c30d2b5d4478b230246dcaaa9f1c533ca3304387 / . / docs / dyn / firebaserules_v1.projects.releases.html
blob: a3f791cf5ba25d9cc1f4bda7f9a5c705a1d49da8 [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
Jon Wayne Parrott0a471d32016-05-19 10:54:38 -0700[diff] [blame]238Args:
239 name: string, Resource name of the `Release`.
240
241
242Format: `projects/{project_id}/releases/{release_id}` (required)
243 x__xgafv: string, V1 error format.
244 Allowed values
245 1 - v1 error format
246 2 - v2 error format
247
248Returns:
249 An object of the form:
250
251 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
252 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
253 "updateTime": "A String", # Time the release was updated.
254 # @OutputOnly
255 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
256 # exist the `Release` to be created.
257 "createTime": "A String", # Time the release was created.
258 # @OutputOnly
259 "name": "A String", # Resource name for the `Release`.
260 #
261 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
262 # which affords developers a great deal of flexibility in mapping the name
263 # to the style that best fits their existing development practices. For
264 # example, a name could refer to an environment, an app, a version, or some
265 # combination of three.
266 #
267 # In the table below, for the project name `projects/foo`, the following
268 # relative release paths show how flat and structured names might be chosen
269 # to match a desired development / deployment strategy.
270 #
271 # Use Case | Flat Name | Structured Name
272 # -------------|---------------------|----------------
273 # Environments | releases/qa | releases/qa
274 # Apps | releases/app1_qa | releases/app1/qa
275 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
276 #
277 # The delimiter between the release name path elements can be almost anything
278 # and it should work equally well with the release name list filter, but in
279 # many ways the structured paths provide a clearer picture of the
280 # relationship between `Release` instances.
281 #
282 # Format: `projects/{project_id}/releases/{release_id}`
283 }</pre>
284</div>
285
286<div class="method">
287 <code class="details" id="list">list(name=None, pageSize=None, filter=None, pageToken=None, x__xgafv=None)</code>
288 <pre>List the `Release` values for a project. This list may optionally be
289filtered by `Release` name or `Ruleset` id or both.
290
291Args:
292 name: string, Resource name for the project.
293
294Format: `projects/{project_id}` (required)
295 pageSize: integer, Page size to load. Maximum of 100. Defaults to 10.
296Note: `page_size` is just a hint and the service may choose to load less
297than `page_size` due to the size of the output. To traverse all of the
298releases, caller should iterate until the `page_token` is empty.
299 filter: string, `Release` filter. The list method supports filters with restrictions on the
300`Release` `name` and also on the `Ruleset` `ruleset_name`.
301
302Example 1) A filter of 'name=prod*' might return `Release`s with names
303within 'projects/foo' prefixed with 'prod':
304
305Name | Ruleset Name
306------------------------------|-------------
307projects/foo/releases/prod | projects/foo/rulesets/uuid1234
308projects/foo/releases/prod/v1 | projects/foo/rulesets/uuid1234
309projects/foo/releases/prod/v2 | projects/foo/rulesets/uuid8888
310
311Example 2) A filter of `name=prod* ruleset_name=uuid1234` would return only
312`Release` instances for 'projects/foo' with names prefixed with 'prod'
313referring to the same `Ruleset` name of 'uuid1234':
314
315Name | Ruleset Name
316------------------------------|-------------
317projects/foo/releases/prod | projects/foo/rulesets/1234
318projects/foo/releases/prod/v1 | projects/foo/rulesets/1234
319
320In the examples, the filter parameters refer to the search filters for
321release and ruleset names are relative to the project releases and rulesets
322collections. Fully qualified prefixed may also be used. e.g.
323`name=projects/foo/releases/prod* ruleset_name=projects/foo/rulesets/uuid1`
324 pageToken: string, Next page token for the next batch of `Release` instances.
325 x__xgafv: string, V1 error format.
326 Allowed values
327 1 - v1 error format
328 2 - v2 error format
329
330Returns:
331 An object of the form:
332
333 { # The response for FirebaseRulesService.ListReleases.
334 "nextPageToken": "A String", # The pagination token to retrieve the next page of results. If the value is
335 # empty, no further results remain.
336 "releases": [ # List of `Release` instances.
337 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
338 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
339 "updateTime": "A String", # Time the release was updated.
340 # @OutputOnly
341 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
342 # exist the `Release` to be created.
343 "createTime": "A String", # Time the release was created.
344 # @OutputOnly
345 "name": "A String", # Resource name for the `Release`.
346 #
347 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
348 # which affords developers a great deal of flexibility in mapping the name
349 # to the style that best fits their existing development practices. For
350 # example, a name could refer to an environment, an app, a version, or some
351 # combination of three.
352 #
353 # In the table below, for the project name `projects/foo`, the following
354 # relative release paths show how flat and structured names might be chosen
355 # to match a desired development / deployment strategy.
356 #
357 # Use Case | Flat Name | Structured Name
358 # -------------|---------------------|----------------
359 # Environments | releases/qa | releases/qa
360 # Apps | releases/app1_qa | releases/app1/qa
361 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
362 #
363 # The delimiter between the release name path elements can be almost anything
364 # and it should work equally well with the release name list filter, but in
365 # many ways the structured paths provide a clearer picture of the
366 # relationship between `Release` instances.
367 #
368 # Format: `projects/{project_id}/releases/{release_id}`
369 },
370 ],
371 }</pre>
372</div>
373
374<div class="method">
375 <code class="details" id="list_next">list_next(previous_request, previous_response)</code>
376 <pre>Retrieves the next page of results.
377
378Args:
379 previous_request: The request for the previous page. (required)
380 previous_response: The response from the request for the previous page. (required)
381
382Returns:
383 A request object that you can call 'execute()' on to request the next
384 page. Returns None if there are no more items in the collection.
385 </pre>
386</div>
387
388<div class="method">
389 <code class="details" id="update">update(name=None, body, x__xgafv=None)</code>
390 <pre>Update a `Release`.
391
392Only updates to the `ruleset_name` field will be honored. `Release` rename
393is not supported. To create a `Release` use the CreateRelease method
394instead.
395
396Args:
397 name: string, Resource name for the `Release`.
398
399`Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
400which affords developers a great deal of flexibility in mapping the name
401to the style that best fits their existing development practices. For
402example, a name could refer to an environment, an app, a version, or some
403combination of three.
404
405In the table below, for the project name `projects/foo`, the following
406relative release paths show how flat and structured names might be chosen
407to match a desired development / deployment strategy.
408
409Use Case | Flat Name | Structured Name
410-------------|---------------------|----------------
411Environments | releases/qa | releases/qa
412Apps | releases/app1_qa | releases/app1/qa
413Versions | releases/app1_v2_qa | releases/app1/v2/qa
414
415The delimiter between the release name path elements can be almost anything
416and it should work equally well with the release name list filter, but in
417many ways the structured paths provide a clearer picture of the
418relationship between `Release` instances.
419
Jon Wayne Parrott7d5badb2016-08-16 12:44:29 -0700[diff] [blame]420Format: `projects/{project_id}/releases/{release_id}` (required)
Jon Wayne Parrott0a471d32016-05-19 10:54:38 -0700[diff] [blame]421 body: object, The request body. (required)
422 The object takes the form of:
423
424{ # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
425 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
426 "updateTime": "A String", # Time the release was updated.
427 # @OutputOnly
428 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
429 # exist the `Release` to be created.
430 "createTime": "A String", # Time the release was created.
431 # @OutputOnly
432 "name": "A String", # Resource name for the `Release`.
433 #
434 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
435 # which affords developers a great deal of flexibility in mapping the name
436 # to the style that best fits their existing development practices. For
437 # example, a name could refer to an environment, an app, a version, or some
438 # combination of three.
439 #
440 # In the table below, for the project name `projects/foo`, the following
441 # relative release paths show how flat and structured names might be chosen
442 # to match a desired development / deployment strategy.
443 #
444 # Use Case | Flat Name | Structured Name
445 # -------------|---------------------|----------------
446 # Environments | releases/qa | releases/qa
447 # Apps | releases/app1_qa | releases/app1/qa
448 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
449 #
450 # The delimiter between the release name path elements can be almost anything
451 # and it should work equally well with the release name list filter, but in
452 # many ways the structured paths provide a clearer picture of the
453 # relationship between `Release` instances.
454 #
455 # Format: `projects/{project_id}/releases/{release_id}`
456 }
457
458 x__xgafv: string, V1 error format.
459 Allowed values
460 1 - v1 error format
461 2 - v2 error format
462
463Returns:
464 An object of the form:
465
466 { # `Release` is a named reference to a `Ruleset`. Once a `Release` refers to a
467 # `Ruleset`, rules-enabled services will be able to enforce the `Ruleset`.
468 "updateTime": "A String", # Time the release was updated.
469 # @OutputOnly
470 "rulesetName": "A String", # Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must
471 # exist the `Release` to be created.
472 "createTime": "A String", # Time the release was created.
473 # @OutputOnly
474 "name": "A String", # Resource name for the `Release`.
475 #
476 # `Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`
477 # which affords developers a great deal of flexibility in mapping the name
478 # to the style that best fits their existing development practices. For
479 # example, a name could refer to an environment, an app, a version, or some
480 # combination of three.
481 #
482 # In the table below, for the project name `projects/foo`, the following
483 # relative release paths show how flat and structured names might be chosen
484 # to match a desired development / deployment strategy.
485 #
486 # Use Case | Flat Name | Structured Name
487 # -------------|---------------------|----------------
488 # Environments | releases/qa | releases/qa
489 # Apps | releases/app1_qa | releases/app1/qa
490 # Versions | releases/app1_v2_qa | releases/app1/v2/qa
491 #
492 # The delimiter between the release name path elements can be almost anything
493 # and it should work equally well with the release name list filter, but in
494 # many ways the structured paths provide a clearer picture of the
495 # relationship between `Release` instances.
496 #
497 # Format: `projects/{project_id}/releases/{release_id}`
498 }</pre>
499</div>
500
501</body></html>