"description":"Time the release was created.\nOutput only.",
"type":"string"
},
"updateTime":{
"type":"string",
"format":"google-datetime",
"description":"Time the release was updated.\nOutput only."
},
"rulesetName":{
"type":"string",
"description":"Name of the `Ruleset` referred to by this `Release`. The `Ruleset` must\nexist the `Release` to be created."
},
"name":{
"type":"string",
"description":"Resource name for the `Release`.\n\n`Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`\nwhich affords developers a great deal of flexibility in mapping the name\nto the style that best fits their existing development practices. For\nexample, a name could refer to an environment, an app, a version, or some\ncombination of three.\n\nIn the table below, for the project name `projects/foo`, the following\nrelative release paths show how flat and structured names might be chosen\nto match a desired development / deployment strategy.\n\nUse Case | Flat Name | Structured Name\n-------------|---------------------|----------------\nEnvironments | releases/qa | releases/qa\nApps | releases/app1_qa | releases/app1/qa\nVersions | releases/app1_v2_qa | releases/app1/v2/qa\n\nThe delimiter between the release name path elements can be almost anything\nand it should work equally well with the release name list filter, but in\nmany ways the structured paths provide a clearer picture of the\nrelationship between `Release` instances.\n\nFormat: `projects/{project_id}/releases/{release_id}`"
}
},
"id":"Release",
"description":"`Release` is a named reference to a `Ruleset`. Once a `Release` refers to a\n`Ruleset`, rules-enabled services will be able to enforce the `Ruleset`."
},
"TestRulesetResponse":{
"description":"The response for FirebaseRulesService.TestRuleset.",
"type":"object",
"properties":{
"testResults":{
"description":"The set of test results given the test cases in the `TestSuite`.\nThe results will appear in the same order as the test cases appear in the\n`TestSuite`.",
"items":{
"$ref":"TestResult"
},
"type":"array"
},
"issues":{
"items":{
"$ref":"Issue"
},
"type":"array",
"description":"Syntactic and semantic `Source` issues of varying severity. Issues of\n`ERROR` severity will prevent tests from executing."
}
},
"id":"TestRulesetResponse"
},
"ListRulesetsResponse":{
"description":"The response for FirebaseRulesService.ListRulesets.",
"type":"object",
"properties":{
"rulesets":{
"description":"List of `Ruleset` instances.",
"items":{
"$ref":"Ruleset"
},
"type":"array"
},
"nextPageToken":{
"type":"string",
"description":"The pagination token to retrieve the next page of results. If the value is\nempty, no further results remain."
}
},
"id":"ListRulesetsResponse"
},
"TestResult":{
"description":"Test result message containing the state of the test as well as a\ndescription and source position for test failures.",
"type":"object",
"properties":{
"errorPosition":{
"$ref":"SourcePosition",
"description":"Position in the `Source` or `Ruleset` where the principle runtime error\noccurs.\n\nEvaluation of an expression may result in an error. Rules are deny by\ndefault, so a `DENY` expectation when an error is generated is valid.\nWhen there is a `DENY` with an error, the `SourcePosition` is returned.\n\nE.g. `error_position { line: 19 column: 37 }`"
},
"functionCalls":{
"items":{
"$ref":"FunctionCall"
},
"type":"array",
"description":"The set of function calls made to service-defined methods.\n\nFunction calls are included in the order in which they are encountered\nduring evaluation, are provided for both mocked and unmocked functions,\nand included on the response regardless of the test `state`."
},
"debugMessages":{
"items":{
"type":"string"
},
"type":"array",
"description":"Debug messages related to test execution issues encountered during\nevaluation.\n\nDebug messages may be related to too many or too few invocations of\nfunction mocks or to runtime errors that occur during evaluation.\n\nFor example: ```Unable to read variable [name: \"resource\"]```"
},
"state":{
"enum":[
"STATE_UNSPECIFIED",
"SUCCESS",
"FAILURE"
],
"description":"State of the test.",
"type":"string",
"enumDescriptions":[
"Test state is not set.",
"Test is a success.",
"Test is a failure."
]
}
},
"id":"TestResult"
},
"Arg":{
"description":"Arg matchers for the mock function.",
"type":"object",
"properties":{
"anyValue":{
"$ref":"Empty",
"description":"Argument matches any value provided."
},
"exactValue":{
"description":"Argument exactly matches value provided.",
"type":"any"
}
},
"id":"Arg"
},
"TestSuite":{
"description":"`TestSuite` is a collection of `TestCase` instances that validate the logical\ncorrectness of a `Ruleset`. The `TestSuite` may be referenced in-line within\na `TestRuleset` invocation or as part of a `Release` object as a pre-release\ncheck.",
"type":"object",
"properties":{
"testCases":{
"description":"Collection of test cases associated with the `TestSuite`.",
"items":{
"$ref":"TestCase"
},
"type":"array"
}
},
"id":"TestSuite"
},
"Empty":{
"description":"A generic empty message that you can re-use to avoid defining duplicated\nempty messages in your APIs. A typical example is to use it as the request\nor the response type of an API method. For instance:\n\n service Foo {\n rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty);\n }\n\nThe JSON representation for `Empty` is empty JSON object `{}`.",
"type":"object",
"properties":{},
"id":"Empty"
},
"FunctionMock":{
"type":"object",
"properties":{
"args":{
"items":{
"$ref":"Arg"
},
"type":"array",
"description":"The list of `Arg` values to match. The order in which the arguments are\nprovided is the order in which they must appear in the function\ninvocation."
},
"function":{
"type":"string",
"description":"The name of the function.\n\nThe function name must match one provided by a service declaration."
},
"result":{
"$ref":"Result",
"description":"The mock result of the function call."
}
},
"id":"FunctionMock",
"description":"Mock function definition.\n\nMocks must refer to a function declared by the target service. The type of\nthe function args and result will be inferred at test time. If either the\narg or result values are not compatible with function type declaration, the\nrequest will be considered invalid.\n\nMore than one `FunctionMock` may be provided for a given function name so\nlong as the `Arg` matchers are distinct. There may be only one function\nfor a given overload where all `Arg` values are `Arg.any_value`."
"description":"Position in the `Source` content including its line, column number, and an\nindex of the `File` in the `Source` message. Used for debug purposes."
"description":"`TestCase` messages provide the request context and an expectation as to\nwhether the given context will be allowed or denied. Test cases may specify\nthe `request`, `resource`, and `function_mocks` to mock a function call to\na service-provided function.\n\nThe `request` object represents context present at request-time.\n\nThe `resource` is the value of the target resource as it appears in\npersistent storage before the request is executed.",
"type":"object",
"properties":{
"functionMocks":{
"items":{
"$ref":"FunctionMock"
},
"type":"array",
"description":"Optional function mocks for service-defined functions. If not set, any\nservice defined function is expected to return an error, which may or may\nnot influence the test outcome."
"description":"Optional resource value as it appears in persistent storage before the\nrequest is fulfilled.\n\nThe resource type depends on the `request.path` value.",
"description":"Request context.\n\nThe exact format of the request context is service-dependent. See the\nappropriate service documentation for information about the supported\nfields and types on the request. Minimally, all services support the\nfollowing fields and types:\n\nRequest field | Type\n---------------|-----------------\nauth.uid | `string`\nauth.token | `map\u003cstring, string\u003e`\nheaders | `map\u003cstring, string\u003e`\nmethod | `string`\nparams | `map\u003cstring, string\u003e`\npath | `string`\ntime | `google.protobuf.Timestamp`\n\nIf the request value is not well-formed for the service, the request will\nbe rejected as an invalid argument."
"description":"Name of the `Ruleset`. The ruleset_id is auto generated by the service.\nFormat: `projects/{project_id}/rulesets/{ruleset_id}`\nOutput only.",
"description":"Test `Source` for syntactic and semantic correctness. Issues present, if\nany, will be returned to the caller with a description, severity, and\nsource location.\n\nThe test method may be executed with `Source` or a `Ruleset` name.\nPassing `Source` is useful for unit testing new rules. Passing a `Ruleset`\nname is useful for regression testing an existing rule.\n\nThe following is an example of `Source` that permits users to upload images\nto a bucket bearing their user id and matching the correct metadata:\n\n_*Example*_\n\n // Users are allowed to subscribe and unsubscribe to the blog.\n service firebase.storage {\n match /users/{userId}/images/{imageName} {\n allow write: if userId == request.auth.uid\n && (imageName.matches('*.png$')\n || imageName.matches('*.jpg$'))\n && resource.mimeType.matches('^image/')\n }\n }",
"description":"Tests may either provide `source` or a `Ruleset` resource name.\n\nFor tests against `source`, the resource name must refer to the project:\nFormat: `projects/{project_id}`\n\nFor tests against a `Ruleset`, this must be the `Ruleset` resource name:\nFormat: `projects/{project_id}/rulesets/{ruleset_id}`",
"description":"List `Ruleset` metadata only and optionally filter the results by `Ruleset`\nname.\n\nThe full `Source` contents of a `Ruleset` may be retrieved with\nGetRuleset.",
"description":"Page size to load. Maximum of 100. Defaults to 10.\nNote: `page_size` is just a hint and the service may choose to load less\nthan `page_size` due to the size of the output. To traverse all of the\nreleases, caller should iterate until the `page_token` is empty.",
"type":"integer"
},
"filter":{
"location":"query",
"description":"`Ruleset` filter. The list method supports filters with restrictions on\n`Ruleset.name`.\n\nFilters on `Ruleset.create_time` should use the `date` function which\nparses strings that conform to the RFC 3339 date/time specifications.\n\nExample: `create_time \u003e date(\"2017-01-01\") AND name=UUID-*`",
"description":"Create a `Ruleset` from `Source`.\n\nThe `Ruleset` is given a unique generated name which is returned to the\ncaller. `Source` containing syntactic or semantics errors will result in an\nerror response indicating the first error encountered. For a detailed view\nof `Source` issues, use TestRuleset.",
"description":"List the `Release` values for a project. This list may optionally be\nfiltered by `Release` name, `Ruleset` name, `TestSuite` name, or any\ncombination thereof.",
"description":"`Release` filter. The list method supports filters with restrictions on the\n`Release.name`, `Release.ruleset_name`, and `Release.test_suite_name`.\n\nExample 1: A filter of 'name=prod*' might return `Release`s with names\nwithin 'projects/foo' prefixed with 'prod':\n\nName | Ruleset Name\n------------------------------|-------------\nprojects/foo/releases/prod | projects/foo/rulesets/uuid1234\nprojects/foo/releases/prod/v1 | projects/foo/rulesets/uuid1234\nprojects/foo/releases/prod/v2 | projects/foo/rulesets/uuid8888\n\nExample 2: A filter of `name=prod* ruleset_name=uuid1234` would return only\n`Release` instances for 'projects/foo' with names prefixed with 'prod'\nreferring to the same `Ruleset` name of 'uuid1234':\n\nName | Ruleset Name\n------------------------------|-------------\nprojects/foo/releases/prod | projects/foo/rulesets/1234\nprojects/foo/releases/prod/v1 | projects/foo/rulesets/1234\n\nIn the examples, the filter parameters refer to the search filters are\nrelative to the project. Fully qualified prefixed may also be used. e.g.\n`test_suite_name=projects/foo/testsuites/uuid1`"
"description":"Page size to load. Maximum of 100. Defaults to 10.\nNote: `page_size` is just a hint and the service may choose to load fewer\nthan `page_size` results due to the size of the output. To traverse all of\nthe releases, the caller should iterate until the `page_token` on the\nresponse is empty."
"description":"Resource name for the `Release`.\n\n`Release` names may be structured `app1/prod/v2` or flat `app1_prod_v2`\nwhich affords developers a great deal of flexibility in mapping the name\nto the style that best fits their existing development practices. For\nexample, a name could refer to an environment, an app, a version, or some\ncombination of three.\n\nIn the table below, for the project name `projects/foo`, the following\nrelative release paths show how flat and structured names might be chosen\nto match a desired development / deployment strategy.\n\nUse Case | Flat Name | Structured Name\n-------------|---------------------|----------------\nEnvironments | releases/qa | releases/qa\nApps | releases/app1_qa | releases/app1/qa\nVersions | releases/app1_v2_qa | releases/app1/v2/qa\n\nThe delimiter between the release name path elements can be almost anything\nand it should work equally well with the release name list filter, but in\nmany ways the structured paths provide a clearer picture of the\nrelationship between `Release` instances.\n\nFormat: `projects/{project_id}/releases/{release_id}`",
"description":"Update a `Release`.\n\nOnly updates to the `ruleset_name` and `test_suite_name` fields will be\nhonored. `Release` rename is not supported. To create a `Release` use the\nCreateRelease method.",
"description":"Create a `Release`.\n\nRelease names should reflect the developer's deployment practices. For\nexample, the release name may include the environment name, application\nname, application version, or any other name meaningful to the developer.\nOnce a `Release` refers to a `Ruleset`, the rules can be enforced by\nFirebase Rules-enabled services.\n\nMore than one `Release` may be 'live' concurrently. Consider the following\nthree `Release` names for `projects/foo` and the `Ruleset` to which they\nrefer.\n\nRelease Name | Ruleset Name\n--------------------------------|-------------\nprojects/foo/releases/prod | projects/foo/rulesets/uuid123\nprojects/foo/releases/prod/beta | projects/foo/rulesets/uuid123\nprojects/foo/releases/prod/v23 | projects/foo/rulesets/uuid456\n\nThe table reflects the `Ruleset` rollout in progress. The `prod` and\n`prod/beta` releases refer to the same `Ruleset`. However, `prod/v23`\nrefers to a new `Ruleset`. The `Ruleset` reference for a `Release` may be\nupdated using the UpdateRelease method.",
"description":"API key. Your API key identifies your project and provides you with API access, quota, and reports. Required unless you provide an OAuth 2.0 token."
"description":"Available to use for quota purposes for server-side applications. Can be any arbitrary string assigned to a user, but should not exceed 40 characters.",
