status¶
rbt status will output a list of your pending review requests
associated with the working directories repository. Review requests which
currently have a draft will be identified by an asterisk (*
).
Optionally pending review requests from all repositories can be displayed
by providing the --all
option.
Usage¶
$ rbt status [options] [review-request [revision]]
JSON Output¶
New in version 3.0.
When running with --json
, the status information will be outputted
as JSON. This can be used by programs that wrap RBTools in order to automate
fetching the status of your changes and providing their own representations.
Successful Payloads¶
When fetching and displaying status is successful, the results are in the form of:
{
"status": "success",
// A list of review requests that are open.
"review_requests": [
{
// The reason a change is not yet approved.
"approval_failure": "<string>",
// Whether a change is approved.
"approved": <bool>,
// The local branch where the change resides, if known.
"branch": "<string>",
// The review request description.
"description": "<string>",
// Whether the review request currently has a draft.
"has_draft": <bool>,
// The number of open issues on the review request.
"open_issue_count": <int>,
// The ID of the review request.
"review_request_id": <int>,
// The URL of the review request.
"review_request_url": "<string>",
// The number of Ship Its on the review request.
"shipit_count": <int>,
// A human-readable string showing the current status.
"status": "<string>",
// The summary of the review request.
"summary": "<string>",
},
...
]
}
The approved
and approval_failure
will reflect the Review Board
server’s approval logic, which can be customized using
ReviewRequestApprovalHook.
Here’s an example of the payload:
$ rbt status --json
{
"review_requests": [
{
"approval_failure": "The review request has not been marked \"Ship It!\"",
"approved": false,
"branch": "my-feature1",
"description": "Description of the change...",
"has_draft": true,
"open_issue_count": 0,
"review_request_id": 123,
"review_request_url": "https://example.com/r/123/",
"shipit_count": 0,
"status": "Pending",
"summary": "Summary of the change...",
},
{
"approval_failure": null,
"approved": true,
"branch": "my-feature2",
"description": "Description of the change...",
"has_draft": false,
"open_issue_count": 0,
"review_request_id": 124,
"review_request_url": "https://example.com/r/124/",
"shipit_count": 1,
"status": "Ship It! (1)",
"summary": "Summary of the change...
}
]
}
Error Payloads¶
When there’s an unexpected error fetching status, the results will be in the form of:
{
"status": "failed",
// A list of errors from the operation.
"errors": [
"<string>",
...
]
}
For example:
$ rbt status --json
{
"errors": [
"An unknown error occurred."
],
"status": "failed"
}
Options¶
-
--format
¶
Set the output format. The format is in the form of
%%(field_name)s
, wherefield_name
is one of:id
,status
,summary
, ordescription
.A character escape can be included via
\xXX
whereXX
the hex code of a character.For example:
--format="%%(id)sx09%%(summary)s"
This option will print out the ID and summary tab-separated. This is incompatible with
--json
.
-
-z
¶
Null-terminate each entry. Otherwise, the entries will be newline-terminated. This is incompatible with
--json
.
-
--all
¶
Shows review requests for all repositories instead of just the detected repository.
-
-d
,
--debug
¶
Displays debug output.
This information can be valuable when debugging problems running the command.
The default can be set in
DEBUG
in .reviewboardrc.
-
--json
¶
Output results as JSON data instead of text.
The default can be set in
JSON_OUTPUT
in .reviewboardrc.New in version 3.0.
Review Board Server Options¶
Options necessary to communicate and authenticate with a Review Board server.
-
--server
<url>
¶ Specifies the Review Board server to use.
The default can be set in
REVIEWBOARD_URL
in .reviewboardrc.
-
--username
<username>
¶ The user name to be supplied to the Review Board server.
The default can be set in
USERNAME
in .reviewboardrc.
-
--password
<password>
¶ The password to be supplied to the Review Board server.
The default can be set in
PASSWORD
in .reviewboardrc.
Use an external cookie store with pre-fetched authentication data. This is useful with servers that require extra web authentication to access Review Board, e.g. on single sign-on enabled sites.
The default can be set in
EXT_AUTH_COOKIES
in .reviewboardrc.New in version 0.7.5.
-
--api-token
<token>
¶ The API token to use for authentication, instead of using a username and password.
The default can be set in
API_TOKEN
in .reviewboardrc.New in version 0.7.
-
--disable-proxy
¶
Prevents requests from going through a proxy server.
The default can be set in
ENABLE_PROXY
in .reviewboardrc.
-
--disable-ssl-verification
¶
Disable SSL certificate verification. This is useful with servers that have self-signed certificates.
The default can be set in
DISABLE_SSL_VERIFICATION
in .reviewboardrc.New in version 0.7.3.
Use an in-memory cookie store instead of writing them to a file. No credentials will be saved or loaded.
The default can be set in
SAVE_COOKIES
in .reviewboardrc.New in version 0.7.3.
-
--disable-cache
¶
Disable the HTTP cache completely. This will result in slower requests.
The default can be set in
DISABLE_CACHE
in .reviewboardrc.New in version 0.7.3.
-
--disable-cache-storage
¶
Disable storing the API cache on the filesystem, instead keeping it in memory temporarily.
The default can be set in
IN_MEMORY_CACHE
in .reviewboardrc.New in version 0.7.3.
-
--cache-location
<file>
¶ The file to use for the API cache database.
The default can be set in
CACHE_LOCATION
in .reviewboardrc.New in version 0.7.3.
-
--ca-certs
<file>
¶ Additional TLS CA bundle.
The default can be set in
CA_CERTS
in .reviewboardrc.
-
--client-key
<file>
¶ Key for TLS client authentication.
The default can be set in
CLIENT_KEY
in .reviewboardrc.
-
--client-cert
<file>
¶ Certificate for TLS client authentication.
The default can be set in
CLIENT_CERT
in .reviewboardrc.
Value of the Proxy-Authorization header to send with HTTP requests.
The default can be set in
PROXY_AUTHORIZATION
in .reviewboardrc.
Repository Options¶
-
--repository
<name>
¶ The name of the repository configured on Review Board that matches the local repository.
The default can be set in
REPOSITORY
in .reviewboardrc.
-
--repository-url
<url>
¶ The URL for a repository.
When generating diffs, this can be used for creating a diff outside of a working copy (currently only supported by Subversion with specific revisions or
--diff-filename
, and by ClearCase with relative paths outside the view).For Git, this specifies the origin URL of the current repository, overriding the origin URL supplied by the client.
The default can be set in
REPOSITORY_URL
in .reviewboardrc.Changed in version 0.6: Prior versions used the
REPOSITORY
setting in.reviewboardrc
, and allowed a repository name to be passed to--repository-url
. This is no longer supported in 0.6 and higher. You may need to update your configuration and scripts appropriately.
-
--repository-type
<type>
¶ The type of repository in the current directory. In most cases this should be detected automatically, but some directory structures containing multiple repositories require this option to select the proper type. The rbt list-repo-types command can be used to list the supported values.
The default can be set in
REPOSITORY_TYPE
in .reviewboardrc.
Perforce Options¶
Perforce-specific options for selecting the Perforce client and communicating with the repository.
-
--p4-client
<client name>
¶ The Perforce client name for the repository.
The default can be set in
P4_CLIENT
in .reviewboardrc.
-
--p4-port
<port>
¶ The IP address for the Perforce server.
The default can be set in
P4_PORT
in .reviewboardrc.
-
--p4-passwd
<password>
¶ The Perforce password or ticket of the user in the P4USER environment variable.
The default can be set in
P4_PASSWD
in .reviewboardrc.
TFS Options¶
Team Foundation Server specific options for communicating with the TFS server.
-
--tfs-login
<tfs login>
¶ Logs in to TFS as a specific user (ie.user@domain,password). Visit https://msdn.microsoft.com/en-us/library/hh190725.aspx to learn about saving credentials for reuse.
-
--tf-cmd
<tf cmd>
¶ The full path of where to find the tf command. This overrides any detected path.
The default can be set in
TF_CMD
in .reviewboardrc.
-
--tfs-shelveset-owner
<tfs shelveset owner>
¶ When posting a shelveset name created by another user (other than the one who owns the current workdir), look for that shelveset using this username.