The path to the archive file.

The archive type. Supported types: AUTO, JAR, ZIP, TAR, and TAR_GZ. 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.

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

Zero or more endpoints that the migration will have access for read and/or write. This is a field that should be defined as:
<br> endpoint = struct(<br> some_endpoint = foo.foo_api(...configuration...),<br> other_endpoint = baz.baz_api(...configuration...),<br> )<br>
Then they will be accessible in the action as ctx.endpoints.some_endpoint and ctx.endpoints.other_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/PATCHES/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 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]+"}

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.

DEPRECATED: DO NOT USE
A list of feedback actions to perform, with the following semantics:
- There is no guarantee of the order of execution.
- Actions need to be independent from each other.
- Failure in one action might prevent other actions from executing.

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

under development

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".

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.

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. Any line that matches any expression in this set, which might otherwise be transformed, will be ignored. Furthermore, it is not possible to ignore a selected text, and replace another, if they exist on the same line. The entire line will be ignored. Note that ignore is matched to the whole file, not just the parts that match before comparing the to-be-transformed string to the ignore regexes, meaning text outside the transform may be used to determine whether or not to apply a transformation.

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.

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 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.

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.

Available variables:

• ${copybara_config_path}: Main config file path
• ${copybara_workflow_name}: The name of the workflow being run
• ${copybara_reference}: The requested reference. In general Copybara tries its best to give a repetable reference. For example Gerrit change number or change-id or GitHub Pull Request number. If it cannot find a context reference it uses the resolved revision.
• ${label:label_name}: A label present for the current change. Exposed in the message or not.

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

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 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 timestamp of when the change was last updated.

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.

Indicates the URL to push to as well as the URL from which to get the parent commit

Reference to use for pushing the change, for example 'main'.

A template string that refers to a tag name. If tag_name exists, overwrite this tag only if flag git-tag-overwrite is set. Note that tag creation is best-effort and migration will succeed even if the tag cannot be created. Usage: Users can use a string or a string with a label. For instance ${label}_tag_name. And the value of label must be in changes' label list. Otherwise, tag won't be created.

A template string that refers to the commit msg of a tag. If set, we will create an annotated tag when tag_name is set. Usage: Users can use a string or a string with a label. For instance ${label}_message. And the value of label must be in changes' label list. Otherwise, tag will be created with sha1's commit msg.

Indicates the ref from which to get the parent commit. Defaults to push value if None

This is an experimental feature that only works for certain origin globs.

Integrate changes from a url present in the migrated change label. Defaults to a semi-fake merge if COPYBARA_INTEGRATE_REVIEW label is present in the message

When enabled, copybara will ignore the 'push' and 'fetch' params if either is 'master' or 'main' and instead try to establish the default git branch. If this fails, it will fall back to the param's declared value.
This is intended to help migrating to the new standard of using 'main' without breaking users relying on the legacy default.

A checker that can check leaks or other checks in the commit created.

EXPERIMENTAL: Read credentials from config file to access the Git Repo.

Indicates the Gerrit repo URL.

A checker for the Gerrit API transport.

Enable the submit_change method

Indicates the URL to push to as well as the URL from which to get the parent commit

Indicates the ref from which to get the parent commit

Review branch to push the change to, for example setting this to 'feature_x' causes the destination to push to 'refs/for/feature_x'. It defaults to 'fetch' value.

If true, skip the push thru Gerrit refs/for/branch and directly push to branch. This is effectively a git.destination that sets a Change-Id

This is an experimental feature that only works for certain origin globs.

Type of Gerrit notify option (https://gerrit-review.googlesource.com/Documentation/user-upload.html#notify). Sends notifications by default.

What to do in the presence or absent of Change-Id in message:

• 'REQUIRE': Require that the change_id is present in the message as a valid label
• 'FAIL_IF_PRESENT': Fail if found in message
• 'REUSE': Reuse if present. Otherwise generate a new one
• 'REPLACE': Replace with a new one if found

By default Copybara will upload a new PatchSet to Gerrit without checking the previous one. If this set to false, Copybara will download current PatchSet and check the diff against the new diff.

The list of the reviewers will be added to gerrit change reviewer listThe element in the list is: an email, for example: "foo@example.com" or label for example: ${SOME_GERRIT_REVIEWER}. These are under the condition of assuming that users have registered to gerrit repos

The list of the email addresses or users that will be CCed in the review. Can use labels as the reviewers field.

The list of labels to be pushed with the change. The format is the label along with the associated value. For example: Run-Presubmit+1

A checker for the Gerrit API endpoint provided for after_migration hooks. This field is not required if the workflow hooks don't use the origin/destination endpoints.

Integrate changes from a url present in the migrated change label. Defaults to a semi-fake merge if COPYBARA_INTEGRATE_REVIEW label is present in the message

Sets the topic of the Gerrit change created.

By default it sets no topic. This field accepts a template with labels. For example: "topic_${CONTEXT_REFERENCE}"

By default, Copybara uses git commit/push to the main branch when submit = True. If this flag is enabled, it will update the Gerrit change with the latest commit and submit using Gerrit.

When enabled, copybara will ignore the 'push_to_refs_for' and 'fetch' params if either is 'master' or 'main' and instead try to establish the default git branch. If this fails, it will fall back to the param's declared value.
This is intended to help migrating to the new standard of using 'main' without breaking users relying on the legacy default.

A checker that validates the commit files & message. If api_checker is not set, it will also be used for checking API calls. If only api_checkeris used, that checker will only apply to API calls.

EXPERIMENTAL: Read credentials from config file to access the Git Repo.

Indicates the URL of the git repository

DEPRECATED. Use git.origin for submitted branches.

Download submodules. Valid values: NO, YES, RECURSIVE.

A list of names (not paths, e.g. "foo" is the submodule name if [submodule "foo"] appears in the .gitmodules file) of submodules that will not be download even if 'submodules' is set to YES or RECURSIVE.

If true, it only uses the first parent when looking for changes. Note that when disabled in ITERATIVE mode, it will try to do a migration for each change of the merged branch.

If true, partially fetch git repository by only fetching affected files.

A checker for the Gerrit API endpoint provided for after_migration hooks. This field is not required if the workflow hooks don't use the origin/destination endpoints.