Expected path of the generated archive file.

An optional glob to describe the list of file paths that are to be included in the archive. If not specified, all files under the current working directory will be included. Note, the original file path in the filesystem will be preserved when archiving it.

The path to the archive file.

The archive type. Supported types: AUTO, JAR, ZIP, TAR, TAR_GZ, TAR_XZ, and TAR_BZ2. AUTO will try to infer the archive type automatically.

The path to extract the archive to. This defaults to the directory where the archive is located.

An optional glob that is used to filter the files extracted from the archive.

The email of the author

The name of the author

The default author for commits in the destination. This is used in squash mode workflows or when users are not on the list.

List of authors in the origin that are allowed to contribute code. The authors must be unique

The default author for commits in the destination

The default author for commits in the destination. This is used in squash mode workflows or if author cannot be determined.

The list of buildozer transforms to combine.

Specifies the Buildozer command, e.g. 'replace deps :foo :bar'

The reverse of the command. This is only required if the given command cannot be reversed automatically and the reversal of this command is required by some workflow or Copybara check. The following commands are automatically reversible:

• add
• remove (when used to remove element from list i.e. 'remove srcs foo.cc'
• replace

Target to create, including the package, e.g. 'foo:bar'. The package can be '.' for the root BUILD file.

Type of this rule, for instance, java_library.

Commands to populate attributes of the target after creating it. Elements can be strings such as 'add deps :foo' or objects returned by buildozer.cmd.

When supplied, causes this target to be created before the target named by 'before'

When supplied, causes this target to be created after the target named by 'after'

Target to delete, including the package, e.g. 'foo:bar'

Type of this rule, for instance, java_library. Supplying this will cause this transformation to be reversible.

Commands to populate attributes of the target after creating it. Elements can be strings such as 'add deps :foo' or objects returned by buildozer.cmd.

When supplied with rule_type and the transformation is reversed, causes this target to be created before the target named by 'before'

When supplied with rule_type and the transformation is reversed, causes this target to be created after the target named by 'after'

Specifies the target(s) against which to apply the commands. Can be a list.

Commands to apply to the target(s) specified. Elements can be strings such as 'add deps :foo' or objects returned by buildozer.cmd.

The TransformWork object

The attribute from the target rule to print.

The target to print from.

The author of the change

Return a ISO offset date time. Example: 2011-12-03T10:15:30+01:00'

The message of the change

A dictionary with the labels detected for the change. If the label is present multiple times it returns the last value. Note that this is a heuristic and it could include things that are not labels.

A dictionary with the labels detected for the change. Note that the value is a collection of the values for each time the label was found. Use 'labels' instead if you are only interested in the last value. Note that this is a heuristic and it could include things that are not labels.

Returns true if the change represents a merge

The message of the change

The author of the change before any mapping

Origin reference ref

First line of this message

The text description this message, not including the labels.

The label name.

List of changes that will be migrated

List of changes that where migrated in previous Copybara executions or if using ITERATIVE mode in previous iterations of this workflow.

the zipped file source

the path to unzip to

A glob relative to the archive root that will restrict what files
from the archive should be extracted.

message to log

message to log

message to log

message to log

message to log

Returns a handle to the console object.

Location of the config file. This is subject to change

The Skylark function to call

The parameters to the function. Will be available under ctx.params

The name of the migration.

The trigger endpoint of the migration. Accessible as ctx.origin

One or more endpoints that the migration will have access for read and/or write with one being named 'destination'. This is a field that should be defined as:
<br> endpoint = struct(<br> destination = foo.foo_api(...configuration...),<br> some_endpoint = baz.baz_api(...configuration...),<br> )<br>
Then they will be accessible in the action as ctx.destination and ctx.endpoints.some_endpoint

The action to execute when the migration is triggered.

A description of what this workflow achieves

If true, the migration provide access to the filesystem to the endpoints

A string to include at the beginning of each patch file

Suffix to use when saving patch files

Directory prefix used to relativize filenames when writing patch files. E.g. if filename is third_party/foo/bar/bar.go and we want to write third_party/foo/AUTOPATCHES/bar/bar.go, the value for this field would be 'third_party/foo'

Directory in which to save the patch files.

When true, strip filenames and line numbers from patch files

When true, strip filenames from patch files

When true, strip line numbers from patch files

Only create patch files that match glob. Default is to match all files

The path to the consistency file. Must end with .bara.consistency.

Exclude BUILD files from being hashed in consistency files.

The expected encoding of the files before transformation. Charset should be in the format expected by https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html

The encoding to convert to. Same format as 'before'

The files to be deleted

The name of the file or directory to copy. If this is the empty string and 'after' is a directory, then all files in the workdir will be copied to the sub directory specified by 'after', maintaining the directory tree.

The name of the file or directory destination. If this is the empty string and 'before' is a directory, then all files in 'before' will be copied to the repo root, maintaining the directory tree inside 'before'.

A glob expression relative to 'before' if it represents a directory. Only files matching the expression will be copied. For example, glob(["**.java"]), matches all java files recursively inside 'before' folder. Defaults to match all the files recursively.

Overwrite destination files if they already exist. Note that this makes the transformation non-reversible, since there is no way to know if the file was overwritten or not in the reverse workflow.

A set of named regexes that can be used to match part of the file name. Copybara uses re2 syntax. For example {"x": "[A-Za-z]+"}

A callable comparator of two strings as a callable. The comparator should take two strings arguments named 'left' and 'right' and return -1, 0, or 1.

Only versions that match this regex will be considered.

The Skylark function to call

The parameters to the function. Will be available under ctx.params

The Skylark function to call

The parameters to the function. Will be available under ctx.params

The noop message

The name of the feedback workflow.

The trigger of a feedback migration.

Where to write change metadata to. This is usually a code review system like Gerrit or GitHub PR.

An action to execute when the migration is triggered

A description of what this workflow achieves

A re2 regex to match a substring of the file

A mapping function like core.replace_mapper or a dict with mapping values.

Extract a regex group from the matching text and pass this as parameter to the mapping instead of the whole matching text.

A glob expression relative to the workdir representing the files to apply the transformation. For example, glob(["**.java"]), matches all java files recursively. Defaults to match all the files recursively.

A re2 regex used as reverse transformation

The format string

The arguments to format

The format of the version. If using it for git, it has to use the completerefspec (e.g. 'refs/tags/${n0}.${n1}.${n2}')

A set of named regexes that can be used to match part of the versions. Copybara uses re2 syntax. Use the following nomenclature n0, n1, n2 for the version part (will use numeric sorting) or s0, s1, s2 (alphabetic sorting). Note that there can be mixed but the numbers cannot be repeated. In other words n0, s1, n2 is valid but not n0, s0, n1. n0 has more priority than n1. If there are fields where order is not important, use s(N+1) where N ist he latest sorted field. Example {"n0": "[0-9]+", "s1": "[a-z]+"}

Package location (ex. 'google3/third_party/java/foo').

Glob of paths to apply merge_import mode, relative to package_path

Deprecated. Use consistency_file in core.workflow instead. When merging, if a consistency file exists, use it to construct the center of the 3-way merge. This can result in a more accurate merge in some cases, such as when the config file has changed since the last import.

The strategy to use for merging files. DIFF3 shells out to diff3 with the -m flag to perform a 3-way merge. PATCH_MERGE creates a patch file by diffing the baseline and destination files, and then applies the patch to the origin file.

The name of the file or directory before moving. If this is the empty string and 'after' is a directory, then all files in the workdir will be moved to the sub directory specified by 'after', maintaining the directory tree.

The name of the file or directory after moving. If this is the empty string and 'before' is a directory, then all files in 'before' will be moved to the repo root, maintaining the directory tree inside 'before'.

A glob expression relative to 'before' if it represents a directory. Only files matching the expression will be moved. For example, glob(["**.java"]), matches all java files recursively inside 'before' folder. Defaults to match all the files recursively.

Overwrite destination files if they already exist. Note that this makes the transformation non-reversible, since there is no way to know if the file was overwritten or not in the reverse workflow.

A set of named regexes that can be used to match part of the file name. Copybara uses re2 syntax. For example {"x": "[A-Za-z]+"}

The files to be deleted

The filepath or suffix to change

A filepath or suffix to use as replacement

A glob expression relative to 'before' if it represents a directory. Only files matching the expression will be renamed. For example, glob(["**.java"]), matches all java files recursively inside 'before' folder. Defaults to match all the files recursively. Note that if reversible transformation is needed, the glob should match the filenames too in that case (or alternatively use an explicit reversal by using core.transformation().

Overwrite destination files if they already exist. Note that this makes the transformation non-reversible, since there is no way to know if the file was overwritten or not in the reverse workflow.

By default before/after match whole path segments. e.g. before = "FOO" wouldn't match example/barFOO. Sometimes only part of the path name needs to be replaced, e.g. renaming extensions. When suffix is set to true, it will match partial parts of the path string.

The text before the transformation. Can contain references to regex groups. For example "foo${x}text".<p>`before` can only contain 1 reference to each unique `regex_group`. If you require multiple references to the same `regex_group`, add `repeated_groups: True`.<p>If '$' literal character needs to be matched, '$$' should be used. For example '$$FOO' would match the literal '$FOO'. [Note this argument is a string. If you want to match a regular expression it must be encoded as a regex_group.]

The text after the transformation. It can also contain references to regex groups, like 'before' field.

A set of named regexes that can be used to match part of the replaced text.Copybara uses re2 syntax. For example {"x": "[A-Za-z]+"}

A glob expression relative to the workdir representing the files to apply the transformation. For example, glob(["**.java"]), matches all java files recursively. Defaults to match all the files recursively.

If true, only replaces the first instance rather than all. In single line mode, replaces the first instance on each line. In multiline mode, replaces the first instance in each file.

Whether to replace text that spans more than one line.

Allow to use a group multiple times. For example foo${repeated}/${repeated}. Note that this won't match "fooX/Y". This mechanism doesn't use backtracking. In other words, the group instances are treated as different groups in regex construction and then a validation is done after that.

A set of regexes. If the entire content of any line (or file, if multiline is enabled) matches any expression in this set, then Copybara will not apply this transformation to any text there. Because ignore is matched against the entire line (or entire file under multiline), not just the parts that match before, the ignore regex can refer to text outside the span that would be replaced.

The list of core.replace transformations

Run all the mappings despite a replace happens.

The transformations to reverse

Prefix tag to look for

Mapping of users/strings

Mode for the replace:

• 'MAP_OR_FAIL': Try to use the mapping and if not found fail.
• 'MAP_OR_IGNORE': Try to use the mapping but ignore if no mapping found.
• 'MAP_OR_DEFAULT': Try to use the mapping and use the default if not found.
• 'SCRUB_NAMES': Scrub all names from TODOs. Transforms 'TODO(foo)' to 'TODO'
• 'USE_DEFAULT': Replace any TODO(foo, bar) with TODO(default_string)

A glob expression relative to the workdir representing the files to apply the transformation. For example, glob(["**.java"]), matches all java files recursively. Defaults to match all the files recursively.

Default value if mapping not found. Only valid for 'MAP_OR_DEFAULT' or 'USE_DEFAULT' modes

If set, elements within TODO (with usernames) that match the regex will be ignored. For example ignore = "foo" would ignore "foo" in "TODO(foo,bar)" but not "bar".

The list of transformations to run as a result of running this transformation.

The list of transformations to run as a result of running this transformation in reverse.

Optional string identifier to name this transform. This can be used for better output readability or with the --skip-transforms flag.

WARNING: Deprecated. Use noop_behavior instead.
In case a noop error happens in the group of transformations (Both forward and reverse), it will be ignored, but the rest of the transformations in the group will still be executed. If ignore_noop is not set, we will apply the closest parent's ignore_noop.

How to handle no-op transformations:

• 'IGNORE_NOOP': Any no-ops among the wrapped transformations are ignored.
• 'NOOP_IF_ANY_NOOP': Throws an exception as soon as a single wrapped transformation is a no-op.
• 'NOOP_IF_ALL_NOOP': Ignores no-ops from the wrapped transformations unless they all no-op, in which case an exception is thrown.

The regex pattern to verify. To satisfy the validation, there has to be atleast one (or no matches if verify_no_match) match in each of the files included in paths. The re2j pattern will be applied in multiline mode, i.e. '^' refers to the beginning of a file and '$' to its end. Copybara uses re2 syntax.

A glob expression relative to the workdir representing the files to apply the transformation. For example, glob(["**.java"]), matches all java files recursively. Defaults to match all the files recursively.

If true, the transformation will verify that the RegEx does not match.

If true, the check will also apply on the reversal. The default behavior is to not verify the pattern on reversal.

Optional string that will be included in the failure message.

The name of the workflow.

Where to read from the code to be migrated, before applying the transformations. This is usually a VCS like Git, but can also be a local folder or even a pending change in a code review system like Gerrit.

Where to write to the code being migrated, after applying the transformations. This is usually a VCS like Git, but can also be a local folder or even a pending change in a code review system like Gerrit.

The author mapping configuration from origin to destination.

The transformations to be run for this workflow. They will run in sequence.

A glob or list of files relative to the workdir that will be read from the origin during the import. For example glob(["**.java"]), all java files, recursively, which excludes all other file types, or ['foo.java'] for a specific file.

A glob relative to the root of the destination repository that matches files that are part of the migration. Files NOT matching this glob will never be removed, even if the file does not exist in the source. For example glob([''], exclude = ['/BUILD']) keeps all BUILD files in destination when the origin does not have any BUILD files. You can also use this to limit the migration to a subdirectory of the destination, e.g. glob(['java/src/'], exclude = ['/BUILD']) to only affect non-BUILD files in java/src.

Workflow mode. Currently we support four modes:

• 'SQUASH': Create a single commit in the destination with new tree state.
• 'ITERATIVE': Import each origin change individually.
• 'CHANGE_REQUEST': Import a pending change to the Source-of-Truth. This could be a GH Pull Request, a Gerrit Change, etc. The final intention should be to submit the change in the SoT (destination in this case).
• 'CHANGE_REQUEST_FROM_SOT': Import a pending change from the Source-of-Truth. This mode is useful when, despite the pending change being already in the SoT, the users want to review the code on a different system. The final intention should never be to submit in the destination, but just review or test

Indicates if the tool should try to to reverse all the transformations at the end to check that they are reversible.
The default value is True for 'CHANGE_REQUEST' mode. False otherwise

If set to true, Copybara will validate that the destination didn't change since last-rev import for destination_files. Note that this flag doesn't work for CHANGE_REQUEST mode.

Indicates that the tool should show the diff and require user's confirmation before making a change in the destination.

Run the migration in dry-run mode. Some destination implementations might have some side effects (like creating a code review), but never submit to a main branch.

Run a feedback workflow after one migration happens. This runs once per change in ITERATIVE mode and only once for SQUASH.

Run a feedback workflow after all the changes for this workflow run are migrated. Prefer after_migration as it is executed per change (in ITERATIVE mode). Tasks in this hook shouldn't be critical to execute. These actions shouldn't record effects (They'll be ignored).

By default, Copybara hashes several fields so that each change has an unique identifier that at the same time reuses the generated destination change. This allows to customize the identity hash generation so that the same identity is used in several workflows. At least ${copybara_config_path} has to be present. Current user is added to the hash automatically.<br><br>Available variables:<ul> <li>${copybara_config_path}: Main config file path

Copybara adds labels like 'GitOrigin-RevId' in the destination in order to track what was the latest change imported. For CHANGE_REQUEST workflows it is not used and is purely informational. This field allows to disable it for that mode. Destinations might ignore the flag.

By default CHANGE_REQUEST workflows cannot restore scrubbed files. This flag does a best-effort approach in restoring the non-affected snippets. For now we only revert the non-affected files. This only works for CHANGE_REQUEST mode.

A migration mode that shells out to a diffing tool (default is diff3) to merge all files. The inputs to the diffing tool are (1) origin file (2) baseline file (3) destination file. This can be used to perpetuate destination-only changes in non source of truth repositories.

Configuration that describes the setting for automatic patch file generation

Perform these transformations after merge_import, but before Copybara writes to the destination. Ex: any BUILD file generations that rely on the results of merge_import

By default, Copybara tries to only migrate changes that affect origin_files or config files. This flag allows to include all the changes. Note that it might generate more empty changes errors. In ITERATIVE mode it might fail if some transformation is validating the message (Like has to contain 'PUBLIC' and the change doesn't contain it because it is internal).

DEPRECATED(Remove by 2024/01/01: Use . Use this label name instead of the one provided by the origin.

If the destination uses labels to mark the last change migrated, use this label name instead of the one provided by the origin. This allows to to have two migrations to the same destination without the other migration changes interfering this migration. I can also serve to clearly state where the change is coming from.

A description of what this workflow achieves

Allows disabling the checkout. The usage of this feature is rare. This could be used to update a file of your own repo when a dependant repo version changes and you are not interested on the files of the dependant repo, just the new version.

Ignore the files matching the glob in the reversible check

Under development. Must end with .bara.consistency

Consistency file configuration. Can be a boolean or a consistency_file_config object. If set to True, consistency file path defaults to "do-not-edit.bara.consistency".

A name for this secret.

The secret value.

The open value.

Dot path to the data field containing the credential.

Username credential.

Password credential.

Epoch time in seconds.

The timezone. E.g. America/New_York, Asia/Tokyo, Europe/Rome, etc.

The timezone. E.g. America/New_York, Asia/Tokyo, Europe/Rome

Destination reference updated/created. Might be null if there was no effect. Might be set even if the type is error (For example a synchronous presubmit test failed but a review was created).

List of errors that happened during the migration

List of origin changes that were included in this migration

Textual summary of what happened. Users of this class should not try to parse this field.

Return the type of effect that happened: CREATED, UPDATED, NOOP, INSUFFICIENT_APPROVALS or ERROR

Files to copy to the workdir, potentially overwriting files checked out from the origin.

Optional path to copy the files to

Path to the file.

Path to the file.

Destination reference id

Type of reference created. Each destination defines its own and guarantees to be more stable than urls/ids

Url, if any, of the destination change

The key to look for.

The default value to use (instead of None) if the key is not found.

The key.

a default value if the key is absent.

The key.

a default value if the key is absent.

Either a dictionary or a list of entries. Entries must be tuples or lists with exactly two elements: key, value.

Dictionary of additional entries.

The message associated with the result

The result of this action

Return the URL of this endpoint.

The reference.

The type of this reference.

The url associated with this reference, if any.

The reference.

The name of the current action.

Access labels that a user passes through flag '--labels'. For example: --labels=foo:value1,bar:value2. Then it can access in this way:cli_labels['foo'].

Get an instance of the console to report errors or warnings

An object representing the destination. Can be used to query or modify the destination state

An object that gives access to the API of the configured endpoints

DEPRECATED: The name of the Feedback migration calling this action. Use migration_name instead.

If a migration of type core.action_migration sets filesystem = True, it gives access to the underlying migration filesystem to manipulate files.

The name of the migration calling this action.

An object representing the origin. Can be used to query about the ref or modifying the origin state

Parameters for the function if created with core.action

A list containing string representations of the entities that triggered the event

The error message

The no op message

The summary of this effect

The origin refs

The destination ref

An optional list of errors

The type of migration effect:

• 'CREATED': A new review or change was created.
• 'UPDATED': An existing review or change was updated.
• 'NOOP': The change was a noop.
• 'NOOP_AGAINST_PENDING_CHANGE': The change was a noop, relativeto an existing pending change.
• 'INSUFFICIENT_APPROVALS': The effect couldn't happen because the change doesn't have enough approvals.
• 'ERROR': A user attributable error happened that prevented the destination from creating/updating the change.
• 'STARTED': The initial effect of a migration that depends on a previous one. This allows to have 'dependant' migrations defined by users.
  An example of this: a workflow migrates code from a Gerrit review to a GitHub PR, and a feedback migration migrates the test results from a CI in GitHub back to the Gerrit change.
  This effect would be created on the former one.

The name of the current action.

Access labels that a user passes through flag '--labels'. For example: --labels=foo:value1,bar:value2. Then it can access in this way:cli_labels['foo'].

Get an instance of the console to report errors or warnings

An object representing the destination. Can be used to query or modify the destination state

The list of effects that happened in the destination

An object representing the origin. Can be used to query about the ref or modifying the origin state

Parameters for the function if created with core.action

Get the requested/resolved revision

The error message

The no op message

The summary of this effect

The origin refs

The destination ref

An optional list of errors

The type of migration effect:

• 'CREATED': A new review or change was created.
• 'UPDATED': An existing review or change was updated.
• 'NOOP': The change was a noop.
• 'NOOP_AGAINST_PENDING_CHANGE': The change was a noop, relativeto an existing pending change.
• 'INSUFFICIENT_APPROVALS': The effect couldn't happen because the change doesn't have enough approvals.
• 'ERROR': A user attributable error happened that prevented the destination from creating/updating the change.
• 'STARTED': The initial effect of a migration that depends on a previous one. This allows to have 'dependant' migrations defined by users.
  An example of this: a workflow migrates code from a Gerrit review to a GitHub PR, and a feedback migration migrates the test results from a CI in GitHub back to the Gerrit change.
  This effect would be created on the former one.

A dictionary with the labels detected for the requested/resolved revision.

The template to use

By default folder.origin will refuse any symlink in the migration folder that is an absolute symlink or that refers to a file outside of the folder. If this flag is set, it will materialize those symlinks as regular files in the checkout directory.

Paths of the files to format relative to the workdir.

The type of the files. Can be 'auto', 'bzl', 'build' or 'workspace'. Note that this is not recommended to be set and might break in the future. The default is 'auto'. This mode formats as BUILD files "BUILD", "BUILD.bazel", "WORKSPACE" and "WORKSPACE.bazel" files. The rest as bzl files. Prefer to use those names for BUILD files instead of setting this flag.

If buildifier --lint should be used. This fixes several common issues. Note that this transformation is difficult to revert. For example if it removes a load statement because is not used after removing a rule, then the reverse workflow needs to add back the load statement (core.replace or similar). Possible values: OFF, FIX. Default is OFF

Warnings used in the lint mode. Default is buildifier default

Return the URL of this endpoint.

The Gerrit change id.

The Gerrit change id.

The account owner who votes on label_id. Use 'me' or 'self' if the account owner makes this api call

The name of the label.

The change id or change number.

The revision of the change.

The change id or change number.

What to include in the response. See https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#query-options

The query string to list changes by. See https://gerrit-review.googlesource.com/Documentation/user-search.html#_basic_change_search.

What to include in the response. See https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#query-options

The reference.

The type of this reference.

The url associated with this reference, if any.

The reference.

The Gerrit change id.

The revision for which the comment will be posted.

The review to post to Gerrit.

The Gerrit change id.

The numeric ID of the account.

The email address the user prefers to be contacted through.
Only set if detailed account information is requested.
See option DETAILED_ACCOUNTS for change queries
and options DETAILS and ALL_EMAILS for account queries.

The full name of the user.
Only set if detailed account information is requested.
See option DETAILED_ACCOUNTS for change queries
and option DETAILS for account queries.

A list of the secondary email addresses of the user.
Only set for account queries when the ALL_EMAILS option or the suggest parameter is set.
Secondary emails are only included if the calling user has the Modify Account, and hence is allowed to see secondary emails of other users.

The username of the user.
Only set if detailed account information is requested.
See option DETAILED_ACCOUNTS for change queries
and option DETAILS for account queries.

The numeric ID of the account.

The time and date describing when the approval was made.

The email address the user prefers to be contacted through.
Only set if detailed account information is requested.
See option DETAILED_ACCOUNTS for change queries
and options DETAILS and ALL_EMAILS for account queries.

The full name of the user.
Only set if detailed account information is requested.
See option DETAILED_ACCOUNTS for change queries
and option DETAILS for account queries.

A list of the secondary email addresses of the user.
Only set for account queries when the ALL_EMAILS option or the suggest parameter is set.
Secondary emails are only included if the calling user has the Modify Account, and hence is allowed to see secondary emails of other users.

The username of the user.
Only set if detailed account information is requested.
See option DETAILED_ACCOUNTS for change queries
and option DETAILS for account queries.

The vote that the user has given for the label. If present and zero, the user is permitted to vote on the label. If absent, the user is not permitted to vote on that label.

The name of the target branch.
The refs/heads/ prefix is omitted.

The Change-Id of the change.

The timestamp of when the change was created.

The commit ID of the current patch set of this change.
Only set if the current revision is requested or if all revisions are requested.

The ID of the change in the format "<project>~<branch>~<Change-Id>", where 'project', 'branch' and 'Change-Id' are URL encoded. For 'branch' the refs/heads/ prefix is omitted.

The labels of the change as a map that maps the label names to LabelInfo entries.
Only set if labels or detailed labels are requested.

Messages associated with the change as a list of ChangeMessageInfo entities.
Only set if messages are requested.

The legacy numeric ID of the change.

The owner of the change as an AccountInfo entity.

The name of the project.

All patch sets of this change as a map that maps the commit ID of the patch set to a RevisionInfo entity.
Only set if the current revision is requested (in which case it will only contain a key for the current revision) or if all revisions are requested.

The status of the change (NEW, MERGED, ABANDONED).

The subject of the change (header line of the commit message).

A list of the evaluated submit requirements for the change.

Whether the change has been approved by the project submit rules. Only set if requested via additional field SUBMITTABLE.

The timestamp of when the change was submitted.

The topic to which this change belongs.

The ID of the change in the format "''", where 'project' and 'branch' are URL encoded. For 'branch' the refs/heads/ prefix is omitted.

The timestamp of when the change was last updated.

Whether the change is marked as "Work in progress".

Author of the message as an AccountInfo entity.
Unset if written by the Gerrit system.

The timestamp of when this identity was constructed.

The ID of the message.

The text left by the user.

Real author of the message as an AccountInfo entity.
Set if the message was posted on behalf of another user.

Which patchset (if any) generated this message.

Value of the tag field from ReviewInput set while posting the review. NOTE: To apply different tags on on different votes/comments multiple invocations of the REST call are required.

The author of the commit as a GitPersonInfo entity.

The commit ID. Not set if included in a RevisionInfo entity that is contained in a map which has the commit ID as key.

The committer of the commit as a GitPersonInfo entity.

The commit message.

The parent commits of this commit as a list of CommitInfo entities. In each parent only the commit and subject fields are populated.

The subject of the commit (header line of the commit message).

If true the action is permitted at this time and the caller is likely allowed to execute it.

Short title to display to a user describing the action

The timestamp of when this identity was constructed.

The email address of the author/committer.

The name of the author/committer.

List of all approvals for this label as a list of ApprovalInfo entities. Items in this list may not represent actual votes cast by users; if a user votes on any label, a corresponding ApprovalInfo will appear in this list for all labels.

One user who approved this label on the change (voted the maximum value) as an AccountInfo entity.

If true, the label blocks submit operation. If not set, the default is false.

The default voting value for the label. This value may be outside the range specified in permitted_labels.

One user who disliked this label on the change (voted negatively, but not the minimum value) as an AccountInfo entity.

One user who recommended this label on the change (voted positively, but not the maximum value) as an AccountInfo entity.

One user who rejected this label on the change (voted the minimum value) as an AccountInfo entity.

The voting value of the user who recommended/disliked this label on the change if it is not "+1"/"-1".

A map of all values that are allowed for this label. The map maps the values ("-2", "-1", "0", "+1", "+2") to the value descriptions.

The commit ID. Not set if included in a RevisionInfo entity that is contained in a map which has the commit ID as key.

The subject of the commit (header line of the commit message).

Map of labels to values after the review was posted.

If true, the change was moved from WIP to ready for review as a result of this action. Not set if false.

The commit of the patch set as CommitInfo entity.

The timestamp of when the patch set was created.

The change kind. Valid values are REWORK, TRIVIAL_REBASE, MERGE_FIRST_PARENT_UPDATE, NO_CODE_CHANGE, and NO_CHANGE.

The patch set number, or edit if the patch set is an edit.

The Git reference for the patch set.

The uploader of the patch set as an AccountInfo entity.

The submit requirement expression as a string.

If true, this submit requirement result was created from a legacy SubmitRecord. Otherwise, it was created by evaluating a submit requirement.

The status of the submit requirement evaluation.